Roadmap checklist

The running state of the build. Tick items as they land. Anything not ticked is not done, whatever a branch name says.

Source of truth for why each item exists: docs/superpowers/specs/2026-09-20-erp-architecture-design.md. Sections cited below are that document’s. Operating a deployment: RUNBOOK.md and DEPLOY_NOTES.md.

Decided before the ledger held data

Closed 2026-09-20, between the Phase 0 merge and Plan 2. Rationale in §17 of the spec.

Multi-entity / consolidation — org_id is the posting dimension. No entity_id. One org = one legal entity; a group onboards as several orgs and consolidation is a Phase 2+ reporting concern. (§17.1)
Base currency scope — per organization, on the company profile. (§17.2)
Tenant data retention and deletion — export, then anonymize in place. Never hard delete; the append-only ledger keeps no sanctioned deletion path. (§17.3)
Delegation and thresholds — the delegate acts on the delegator’s thresholds, and the decision log records both. (§17.4)

Phase 0 — Foundation

Plan: 2026-09-20-phase-0-foundation.md

Carried out of Phase 0 — read before Plan 1 or Plan 2.

CLOSED (Plan 2 Task 12) — Tenant() no longer reads an organization from a header. The Phase 0 placeholder trusted an unauthenticated header, so any caller could assert any org. Tenant() now reads the organization out of the verified access token that Authenticate() placed on the request context, and nothing else. TestNothingReadsAnOrgFromAHeader in internal/kernel/layering scans internal, cmd and api — .go and .yaml — and fails the build if any file reintroduces an org header. Routes serving real tenant data may now be registered under /v1.
The first task adding a NUMERIC column or a monetary API field must configure a sqlc and oapi-codegen type override onto money.Amount. No override exists today because nothing monetary exists yet. Without one, a monetary column generates as float64 — the defect the money invariant exists to prevent, landing silently. — done in Plan 4 Task 18 (Money → money.Amount, Rate → money.Rate)
Amend §Global Constraints: the Go floor is 1.26, not 1.23. pressly/goose/v3 requires it, and CI derives its version from go.mod rather than restating one. — spec §2 and the Phase 0 plan amended; go.mod says go 1.26.0, CI uses go-version-file: 'go.mod'
Two tables carry a nullable org_id by declaration — expense_category and translation — recorded with justifications in db/org_id_nullable.txt, and kernel/db/rlscoverage_test.go fails on any undeclared one. A global registry row belongs to no tenant. Any new registry follows the 00005_registry.sql pattern, including its WITH CHECK clause.

Statutory compliance — a standing constraint

Malaysian audit compliance is checked at design time, not added at the end. The binding requirements and their statutory references are §11A of the spec. Not yet reviewed by a tax agent — that must happen before any paying customer’s data lands.

Records stay in Malaysia (ITA s.82(8)) — VPS, volumes, object store and every backup in a Malaysian datacenter; no offshore processor touches record data, including OCR. A deployment fact, not a code path: checked at provisioning against RUNBOOK §1 (VPS, Postgres volume, DB backups and WAL archives, bucket and its backups, OCR off). The code backs it where it can: no default object-store endpoint, and any OCR_PROVIDER is refused at boot.
Seven-year retention outranks erasure (ITA s.82A) — anonymization suspends until a row’s retention clock expires.
- Spec amended (§17.3 item 3, §11A.2); statutory rows undeletable by the app role (00015_retention_grants, enforced by kernel/db/retention_test.go)
- Retention-gated anonymization path and its §11A.7 test (“no anonymization path may run against a row inside its retention window”) — built with tenant erasure / export (§17.3). No erasure path exists yet, so nothing can breach it today.
ms locale is statutory — record-bearing free text restricted to en / ms; zh is a UI locale only. Done for expense claims (expenses.CheckRecordText plus named CHECKs in 00072; category names required in en and ms). Being done on phase1-wave3: ms added to locale.Supported (the workflow validator refused ms labels without it) and the en/ms record-text check applied to journal text and party names. Tick when the base merges.
Audit trail is tamper-evident — prev_hash / row_hash chain on audit_log, with a verification pass CI proves can fail. — Plan 2 Task 1: 00007, VerifyChain; chain_test.go proves an altered, excised or tampered row fails; audit_chain reconcile check before every close; migrate verify-audit
Claim lines carry the tax record — supplier_tin, einvoice_uuid, document_basis, and employee_named_document_allowed on the category. Phase 1, because identifiers cannot be backfilled onto settled documents. — Plan 5 (Tasks 9, 11, 13)
e-Invoice submission stays Phase 2 — the issuing obligation is a sales-side concern Phase 1 does not build. Inbound capture is Phase 1 (claim lines, above).

Phase 1 — Expense and accounting core

Nine plans, in this order. 2 and 2b before 3, because grants bind to positions and the country pack needs the company profile. 3 and 4 before 5, because building claims first is how the logic ends up inside claims again. (§16)

Status (2026-09-24): Plans 2, 2b, 3, 4, 5, 6, 8 and 10 and the Wave 3 base are done. Phase 1 closes when Plan 7’s reminder delivery (waits for a mailer) and Plan 9’s aged-advances and float-register reports land.

Phase 2 — Payables, receivables and MY compliance

Makes it an accounting system rather than a claims system. (§19)

Needs an outside authority

From the owner-confirmations pass (2026-09-29). Every line here has a system behaviour that stands until the named authority confirms otherwise; none of them block using the system today.

Bank file format (payment batches) — the customer’s bank (Maybank2u Biz, CIMB BizChannel, etc.) must supply its DuitNow bulk / IBG upload specification. Until then: generic_csv_v1, labelled “not a bank format” in the download dialog.
Bank identifiers (payment batches) — the same bank supplies its beneficiary-bank code table (PayNet participant codes / BIC). Until then: the file names the bank by registry key and name only.
SST-02 form part references — a licensed tax agent maps every field to the current SST-02 (and SST-02A) form. Until then: every export keeps the “(unverified)” stamp.
WHT rates and sections — a tax agent confirms each seeded rate against ITA 1967, the current LHDN WHT pages and any 2025+ budget changes. Until then: the codes stay editable data, and the register carries a “rates unverified” note.
WHT form letters (CP37/CP37A/CP37D/CP37F) — the same tax-agent pass as item 4. Until then: only the labels are at risk; no behaviour depends on them.
WHT “paid or credited” timing — a tax agent’s written reading of whether LHDN treats crediting to the payee’s books as crediting for s.107A/109/109B/109F. Until then: withholding happens at payment, with a credited_earlier flag shown on the register and in the payment drawer.
WHT taxable base — a tax agent rules whether SST and reimbursements are excluded from the withholding base. Until then: the clerk enters the base, defaulting to the gross settled including SST, with the SST portion shown beside it.
Untested Malaysian bank statement files (bank reconciliation) — an anonymised MT940 and CSV export from Maybank, CIMB, Public Bank, RHB and Hong Leong, added as parser fixtures. Until then: the import screen marks MT940 “untested with your bank”; CSV mapping is the fallback.
MyInvois signing key / certificate — confirm in the LHDN sandbox and SDK FAQ that unsigned version 1.0 is still accepted and until when, and obtain the provider’s digital certificate (MCMC-licensed CA) before go-live. Until then: a boot warning, and a DEPLOY_NOTES sandbox checklist item.
Self-billed foreign-supplier defaults (MyInvois) — sandbox-validate one self-billed document using EI00000000030, MSIC 00000 and NA for missing identifiers. Until then: the defaults stay as coded.
Credit note for a pre-mandate invoice (MyInvois) — sandbox-validate a credit note that references such an invoice with UUID NA. Until then: it stays as coded. 11a. Debit notes 03 and 13 (MyInvois) — UNVERIFIED. The adviser sandbox-validates one customer debit note (type 03) with a BillingReference to a valid original and one without, and one self-billed supplier debit note (type 13), against LHDN’s current guideline: whether 03/13 take BillingReference at all, and that a debit note with an original waits for the original’s UUID as a credit note does (MyInvois D12). Until then: the encoder emits them as written, the golden files debit_note.json and self_billed_debit_note.json are the encoder’s own output, and an organization that cannot wait issues an extra charge as a new invoice (the documented workaround).
Customer receipts and advance payments (MyInvois / AR) — a tax agent confirms against the current LHDN e-Invoice Specific Guideline whether an advance payment received requires its own e-Invoice. Until then: receipts and advances are not e-Invoiced, with a warning shown when a receipt leaves money on account in an in-scope organization.
B2C/foreign buyer TINs (MyInvois, review I4) — sandbox-validate a B2C document naming EI00000000010 with ID and phone sent as NA, checked against LHDN guideline Appendix 1. Until then: an ID document and phone are required for every buyer.
Capital allowance (ITA 1967 Schedule 3) — the tax agent computes initial and annual allowances, balancing adjustments on disposal and the qualifying-expenditure classes (OD-4). Until then: the system keeps book depreciation only (MFRS 116), the fixed asset register and its disposals give the agent cost, in-service and disposal dates and proceeds, and no tax computation depends on it.
Employment Act leave figures (HR, H3) — UNVERIFIED. An HR or legal adviser confirms, against the current Employment Act 1955, the seeded leave_statutory_floor figures (annual 8/12/16 and sick 14/18/22 by under 2 / 2-5 / over 5 years of service; hospitalisation 60; maternity 98 consecutive days; paternity 7 consecutive days, recalled from the 2022 amendments), and the service-month rules they build on (hr.ServiceMonths). Open points: the first-year proration rounding (attributed to s.60E(1A), unconfirmed); whether the 60 hospitalisation days include the sick days rather than add to them; paternity eligibility conditions (not modelled); which employees are covered (some provisions apply only below a wage threshold); whether the service band moves mid-year; retention of employment and leave records; and whether unused annual leave carried over or lost on leaving has statutory treatment. Until then: nothing is seeded per organization. The hr_leave_grants job grants only after an administrator creates an active paid leave type with a rule set in force (the leave module switch does not matter, Ruling H3-18), so grants CAN be made from the unverified statutory floors once rules are entered. The floors bind as seeded; a correction is a migration. A pending record (no hire date) grants none.

Phase 3 — Platform customization

What lets a reseller deploy without engineering. (§19)

Phase 4 — Operations

O1 — document chain (platform/trade, 00700–00709) and item master (platform/inventory, 00710–00719): the committed semantic; requisition, order, quotation and sales-order workflows; copy-forward, open quantity and close, guarded by the database; the invoice-line link; items, units, categories and locations with screens, custom fields and the items import; modules inventory, procurement, sales (plan docs/superpowers/plans/2026-09-30-phase-4-o1-chain-items.md)
Procurement: PR → PO → GRN → purchase invoice, on a generalized document chain (O3: receipts only against an order, the order’s approver kept off its receipt by the database, the three-way match at approval with an audited Owner override, GRNI cleared with price variance to P&L and realised FX, purchase returns and supplier credit notes, purchase-order PDF, open orders and GRNI aging; plan docs/superpowers/plans/2026-09-30-phase-4-o3-procurement-sales.md)
Sales: quotation → SO → DO → invoice, on the same chain (O3: quotation validity and PDF, deliveries at cost, invoiced ≤ delivered − invoiced, sales returns and customer credit notes, open sales orders with backorders, delivered not invoiced; MyInvois unchanged)
Inventory: items, multi-UOM, multi-location, transfers, FIFO and weighted average costing, serial/batch. Costing posts through the posting engine. (O1 + O2: effect semantic, grni, stock_valuation integrity check; web UI for stock is a later lane, R-O2-19; plan docs/superpowers/plans/2026-09-30-phase-4-o2-stock-costing.md)
Fixed assets — operations design 2026-09-30-operations-design.md §O4, plan 2026-09-30-phase-4-o4-fixed-assets.md (00771–00773): asset classes (four accounts, straight line or reducing balance, fixed once created); assets registered from a posted purchase invoice line, a manual journal line or the fixed_asset opening import, never posting; a monthly depreciation run (one manual entry, source depreciation_run, unique per period, caught up after a late registration or a closed month, which is skipped and flagged) run daily by River for the previous month and by hand at Accounting → Depreciation; disposals and write-offs through the asset_disposal workflow, depreciated through the disposal month and posted on O2’s effect; reports (register, schedule forecast, roll-forward, register vs ledger); the asset_register_gl integrity check (nightly, and before every close); module assets. Book depreciation only (OD-4)

Phase 5 — People

Phase 6 — Scale and intelligence

Two-phase company onboarding (added 2026-10-09, owner request; branch `two-phase-onboarding`, not merged)

Design: 2026-10-09-two-phase-onboarding-design.md. The operator creates a company with three fields (name, owner name, owner email); the owner finishes the rest in a first-login wizard. Setup pending = no company_profile row, so no new column and existing companies are unaffected. Migrations 01200-01203.

Invariants — never tick these off, they are permanent

Re-read before any change that touches money, tenancy or the workflow.

A float never touches money, in any layer. Money crosses the wire as a string.
Every business table has org_id, forced RLS and an org_isolation policy.
Every request runs inside a transaction, including reads.
Vocabulary values are strings, never integers.
The ledger is append-only. Corrections are reversals, never mutations.
accounting/ reacts to semantic tags, never state names.
Modules never write journal lines; they register posting rules.
Nothing outside a module imports its internal/.
Every user-facing name is a translation row.
Approval grants are configured by an administrator; a claimant never picks their own approver.