CRB Gap List — 2026-04-28

Pass date: 2026-04-28 | Initiated by: GRO-670 | Executor: ALX | Review gate: Jeffe

Summary

L4 documentation note: The user has source documentation (NCR/Counterpoint API specs, vendor process docs, retail ops references) that can be used to fill L4 activities once the gap list is produced. See Part 4 for the highest-priority L4 targets.

Part 1 — Structural Subsystem GAPs

These are L3 processes where no CanaryGO cmd/ package exists to receive the implementation. Each requires either a new package to be built or an explicit assignment to an existing package before the L3 can be implemented.

1A. Module M — Commercial / B2B (26 L3s — full module GAP)

Root cause: No cmd/commercial package exists in CanaryGO. C is derived from C (Customer) and F (Finance) data; it has no dedicated Counterpoint endpoints of its own.

Build constraint: C requires Module C and Module F to be stable first. It is Module 4 in the v2 ring.

Note: M.4.x (B2B detection rules Q-M-01 through Q-M-05) routes through cmd/chirp — these are not a new-subsystem gap, but they require explicit Q-pipeline extension work documented in Q.

1B. Module O — Orders: Forecasting / ROP / OTB / PO Engine (33 L3s — partial module GAP)

Root cause: cmd/receiving covers O.6 (Receiving) and O.7 (Returns/RTV) — 14 L3s mapped. The remaining 33 L3s covering statistical forecasting, ROP/safety-stock calculation, OTB management, and automated PO generation have no corresponding cmd/ package.

Cross-module dependency: J.8a (promotional demand isolation) requires P.6.3 (promotion calendar) — this is a load-bearing inter-module contract.

Critical path note (O.4.4): O.4.4 is the first place Canary writes back to Counterpoint. This has significant architectural implications — the write-back pattern must be established and tested before O.4.4 can be implemented.

1C. Module E — Execution (~14 L3s — full module GAP, v3)

Root cause: W is a v3 capstone design. No cmd/work or equivalent package exists. No SDD has been written. Implementation depends on Q's Fox evidence-chain infrastructure being stable.

Design reference: canary-module-e-execution.md — all tables and services are projected (no code yet).

Implementation gate: W cannot be implemented until Q's Fox evidence-chain infrastructure is stable and v2 ring modules (C, D, F, J) are shipping.

1D. Module L — Labor (~15 L3s — narrative-only, cmd/employee target)

Root cause: L is a v3 design with no functional decomp file. cmd/employee exists as a named package in CanaryGO but its current scope is unknown. All L3s are INFERRED from the schema crosswalk in the wiki narrative.

Note: All L L3s map to cmd/employee (not a new-package gap), but since cmd/employee's current scope hasn't been inspected against these L3s, all 15 should be validated against the existing package before filing as Mapped.

1E. Miscellaneous Structural GAPs (57 L3s — cross-module)

These are individual L3 processes across otherwise-mapped modules where the specific L3 has no clear subsystem assignment (INFERRED subsystem or boundary ambiguity).

Part 2 — Universal L4 Gap

Every L3 process in the entire CRB corpus (357 total) has L4 marked TBD.

This is not a deficiency of the decomp pass — it reflects that the functional decomp files themselves do not yet specify implementation-level activities. L4 is the atomic step level that maps to individual Go functions, handlers, or jobs.

L4 Gap by Module

L4 Documentation Candidates

The following L3 processes are the highest-leverage targets for documentation-based L4 resolution, because source documents (Counterpoint API spec, RapidPOS, NCR docs, vendor specs) directly describe the implementation steps:

Action: When the user provides documentation for the above, map each source doc to the L3 IDs in this table and derive L4 activities from the documented API parameters, field names, and operation sequences.

Part 3 — Assumption Gaps

These are unresolved assumptions in the functional decomp files that directly block L3 or L4 implementation. Each requires a decision from Jeffe or real-customer validation before the affected L3s can be marked implementation-ready.

Part 4 — Unknown cmd/ Packages

Two cmd/ packages exist in the CanaryGO repo whose module mapping is unconfirmed.

If either package is the authoritative home for one of the structural GAP modules (C, J-forecast, W, or L), the gap count above should be updated accordingly.

Part 5 — Linear Issue Backlog (Phase 4 Input)

The following new Linear issues should be created in Canary.GO as Backlog items with Label Blueprint:

The following existing module epics (GRO-647 through GRO-659) should receive a comment linking to the corresponding decomp file and noting any CONFLICTING findings:

Pass: GRO-670 | Phase 2 complete | Next: Phase 3 — CRB-LINT-REPORT.md