Fibretrace Monet docs/Knowledge base/Open questions (ranked)

Open questions — ranked by how much they block

Each entry: the question, why it matters, the evidence on each side, and who can answer it. Citation shorthand per README.md.

Updated 2026-08-20: Q10 is answered (a real DB-level bug) and Q12 is rewritten and escalated (RLS open to anon on the Lovable MVP Supabase). Both now carry VERIFIED evidence and feed the Malcolm list; the RLS item is tracked as task T91. Note on ordering: Q-numbers are stable identifiers cross-referenced from the persona files and the master report, so they are NOT renumbered when a rank changes. Q12 now ranks second only to Q1 despite its number — it is a data-safety fact about the very instance QC is about to run on, not a scoping question.

Q1 — Which claim model is canonical: the PO propose/confirm state machine, or the single-step REST claim? (BLOCKS THE MOST)

The question: Lovable (and the QC script) implement a two-party machine — manufacturer proposes against a PO, retailer confirms/rejects, DB triggers meter everything. The real backend deployed (2026-08-03) a different, single-step model: POST /api/monet/v1/claims with {program_id, quantity_mt, verification_ids[], retailer_company_id} plus a validate step that is itself still 404 on DEV. Three independent memory records flag these as “parallel, unreconciled models until product/BE states which one is canonical”. Why it matters: this decides the entire BE build for 9 GAP units, whether monet ports the propose/confirm UI as anything more than a shell, and whether QC sections 4-5 describe the product or a prototype. Evidence: L:src/hooks/usePurchaseOrders.ts (full two-party machine, DB-triggered) vs .local/backend-specs/fibre-program/README.md:26-27,52-76 (single-step, PO domain explicitly not covered). Who answers: Malcolm + BE team (product decision, then contract). UNKNOWN

Q2 — Purchase Order -> Nomination: display rename only, or domain rename?

QC X-02 settles the display wording (“Nominations, not Purchase Order”) while the same script still routes /purchase-orders and says “Create a nomination (PO)”. Whether the table/endpoints/domain rename is undecided (“enum unconfirmed post-2026-08-18 rename”, port-plan.md:136). Why it matters: every BE ask for the PO domain needs a name; porting the copy sweep piecemeal leaves the UI half-renamed. Who answers: Malcolm (naming), BE (contract). UNKNOWN

Q3 — CU label: “Claim Unit (CU)” or “credit units”?

Open since 2026-08-18; the QC script uses BOTH and canonises the pair (QC:6,106,276); Lovable’s own 4-pass copy sweep is incomplete at HEAD (claimUnits.ts, CuStat, fmtCu still say CU). Why it matters: blocks the platform-wide terminology sweep (port-plan unit 9) and makes QC X-02 untestable as written. Who answers: Malcolm. UNKNOWN

Q4 — Is the loss multiplier part of the official CU formula for QC math?

The app computes CU with an internal-only loss multiplier (L:AdminProductCategories.tsx:144); QC rule 1 omits it (QC:6). Testers cannot see the multiplier by design. Options: assume loss_multiplier = 1 categories in test data, or give testers the values, or amend the rule. Who answers: Malcolm (and whoever builds QC data). VERIFIED discrepancy, UNKNOWN resolution

Q5 — Insights module (QC A-08, R-13): about to be built, or to be dropped from QC?

No /insights route, no module flag, in Lovable, monet or canvas — and R-13’s named data home (Walmart) is a demo account testers must not touch. Who answers: Malcolm. VERIFIED absence

Q6 — Reservation expiry on the real backend: server-computed expires_at, or folded into the funnel?

Lovable now has expires_at NOT NULL with a defaulting trigger; the real backend has no expires_at concept anywhere (confirmed 2026-08-18). BE must choose: (a) return expires_at per reservation row (needs the row-level GET that also does not exist yet), or (b) exclude expired capacity inside the funnel server-side. Why it matters: ClaimPosition’s reservation history and expiry chips are unbuildable against the real API until decided. Evidence: origin/main SQL 20260816203909 vs port-plan.md:79. Who answers: BE team. UNKNOWN

Q7 — Will the real backend expose row-level reservations, a request queue, and negative entries?

Admin approve/reject routes exist server-side (session-authed), proving the row resource exists, but no tenant GET was ever captured; “Add reservation” on the real backend is a fire-and-forget sales email, not a persisted request. The whole ledger model (per-adjustment rows, negative releases) is a Lovable construct the QC script now tests as expected behaviour. Who answers: BE team (with Malcolm’s ledger decision now on record via the QC script). UNKNOWN

Q8 — QC A-04’s negative entry at /admin/reservation-requests: mislabel or intended feature?

The queue rejects CU <= 0 on both ends by design; negatives live only on the programme panel. Either A-04’s route is wrong or the queue is meant to gain negative support. Who answers: Malcolm (QC author). VERIFIED divergence

Q9 — Non-partner visibility on the supply-chain map: mask or omit?

Malcolm’s demo said non-partners “don’t appear” (BL:demo:83); the code shows them masked as “Confidential supplier” with city/country and an Invite CTA (BL:resolved:20-24; confirmed live). Flagged for his sign-off since July, never ruled. Who answers: Malcolm (+ Jamie). VERIFIED contradiction

Q10 — [ANSWERED 2026-08-20] production_claims status CHECK does NOT allow ‘revoked’ — admin claim revoke is broken at the DB

Settled by a direct code check on 2026-08-20 (task T88), and the answer is the bad branch. The constraint production_claims_status_check allows only (‘proposed’,‘confirmed’,‘rejected’) and is created exactly once, at SQL 20260618105531:20-24 — that is the only migration of all 132 at origin/main touching the constraint name, there is no DROP CONSTRAINT on production_claims anywhere, and no migration at origin/main ever widens that CHECK to include ‘revoked’ (the only ‘revoked’ in any status CHECK belongs to a different table, program_certificates, SQL 20260606025632:77). Yet the revoke feature was deliberately built: SQL 20260811125616:1-4 adds revoked_at, revoked_by_user_id and revoke_reason to production_claims, and L:src/pages/EvidencePackDetail.tsx:137-157 updates status: “revoked” together with those three columns. So the UPDATE violates the CHECK and throws: the error branch fires the “Could not revoke this record” toast, setRevokedLocal(true) never runs, and the public “This verification record has been revoked” banner keyed on status === “revoked” (L:src/pages/PublicClaim.tsx:64,86) is unreachable code. This is a half-migration: the columns landed, the constraint was forgotten. It is NOT a systemic revoke bug — the other revoke site, L:src/pages/owner/OwnerCertificates.tsx:152, writes program_certificates, whose own CHECK was written correctly from the start as (status IN (‘active’,‘revoked’)) with revoked_at alongside it (SQL 20260606025632:77-78), so that revoke works fine — the same author got it right on the other table, which makes the production_claims omission an oversight rather than a pattern. Correction to this entry’s earlier evidence (re-verified 2026-08-20 against origin/main): the 2026-08-20 first draft of this answer said “revoked appears in zero migrations” and “program_certificates carries no status CHECK”; both were wrong and are corrected above, the conclusion is unchanged. Also: usePurchaseOrders.ts:936-956 is the evidence-pack delete flow, not a revoked write; the only production_claims revoke write is EvidencePackDetail.tsx:143. Goes on the Malcolm list (T86). Owner of the fix: Lovable/BE, not monet. VERIFIED

Q11 — Company-level vs facility-level tier

Tier is a self-declared free-text company field; Malcolm himself flagged the model may be wrong for vertically integrated suppliers (Sitex: Tier 1 to one partner, Tier 2 to another). No facility-level tier schema exists. Why it matters: the supply-chain map’s tier ladder and the persona narrative both lean on it. Who answers: Malcolm (data-model decision). STATED, open since July

Q12 — [REWRITTEN 2026-08-20] Lovable’s Supabase RLS is open to anon on every table — the public-token gate is void, not merely bypassed

This entry previously understated the problem, and is rewritten after a direct check on 2026-08-20. The route /api/v1/claims/:claimId/status (L:src/App.tsx:142 -> ClaimWebhookPreview) is only the visible symptom: it is a client-side React page querying Supabase directly, so what is actually exposed is decided by RLS, not by the route. RLS is open to anonymous. production_claims carries CREATE POLICY “Allow full access to production_claims” ON public.production_claims FOR ALL USING (true) WITH CHECK (true) with no TO clause, which defaults to role public and therefore includes anon (SQL 20260421164336:40-44); public_verification_tokens carries the identical policy (SQL 20260611094428:79-80). This is the house style rather than an isolated slip: 79 occurrences of USING (true) across 33 migration files. The heaviest consequence, not previously recorded: public_verification_tokens is anonymously readable, so anyone holding a claimId can read that claim’s token rows and open the public Evidence Pack even when enabled = false — the public-token gate is VOID, not merely routed around. And WITH CHECK (true) means anon can WRITE these tables, not only read them. Scope, stated plainly: this is the Lovable MVP’s own Supabase, which is never monet’s production backend (monet reaches Laravel through apiAdapter.ts), so there is nothing to fix in this repo — but it is exactly the instance the QC round is about to run against and the one Malcolm demos to business stakeholders. Still true from the original entry: “webhook” remains a preview page with no outbound push, while Connections copy promises webhooks that do not exist. Action: tell Malcolm before QC starts (task T91, and first item on the T86 list); who remediates is Lovable/BE. VERIFIED

Q13 — The direct non-PO claim path: keep or kill?

A brand could claim capacity directly (Make-a-claim wizard) without any PO — observed live in July, still DB-legal (claim_verifications was even re-created on 2026-07-22 to support manual claim-scan links), while the UI steers to the PO flow. The real backend’s POST /claims is precisely this shape. If the PO flow is canonical (Q1), what is the manual path’s status? Who answers: Malcolm. STATED + VERIFIED schema support, contradiction unresolved

Q14 — Scanner request flow: is a mailto acceptable for QC M-02?

The in-app “request a scanner” is a mailto to support; admin assignment cannot be triggered by it. Real scanner endpoints also lack facility assignment. QC M-02 assumes an in-app request-assign loop. Who answers: Malcolm (QC wording) / BE (endpoint). VERIFIED divergence

Q15 — Facility licence: count-only or priced?

QC A-12/M-01 expect a licence cost with currency and period; the schema has neither (license_count + subscription_status only); the real backend has license-summary/license-enquiries in yet another shape. Who answers: Malcolm (is pricing in scope?) + BE. VERIFIED divergence

Q16 — SDU-only companies: should they see SDU Device Status?

QC P-01 says an SDU-only company must NOT see Production or SDU Device Status; the sidebar currently shows the SDU item whenever devices exist, regardless of producer registration. Also the deprecated usePersona hook still counts the sdu module as producer — should it be deleted? Who answers: Malcolm (intent), then a small Lovable fix. VERIFIED divergence

Q17 — Production limits at entry (QC P-06)

No client-side guard blocks a production entry exceeding allocation; the ceiling cap is a silent LEAST() in the trigger on the scan-derived figure. Is a blocking validation to be built, or is P-06 wrong? Who answers: Malcolm. VERIFIED absence

Q18 — Tier label drift

Signup wizard labels (“Tier 3 — Fibre producer”, “Tier 4 — Raw material”) vs Malcolm’s definitions (Tier 3 spinner, Tier 4 gin/raw fibre producer). One of them should change. Who answers: Malcolm. VERIFIED divergence

Q19 — Certificates: sub-tier inheritance and the 1:N model

Multiple certificates per transaction is stated (1:N), and whether certificates from connected sub-tiers surface on a claim was unresolved at the demo and remains so; the company-certificates module also has zero BE backing. Who answers: Malcolm + Jamie (product), BE (resource). STATED, open since July

Q20 — Who is the QC script’s target environment, and with what auth settings?

Everything in it fits Lovable HEAD (30/31 routes); running it on monet produces known-gap noise. X-05’s access-control expectations only hold with adminLoginRequired ON, and the companion results CSV was never attached. Who answers: Malcolm (confirm target + settings + send CSV). VERIFIED analysis

Lower-priority code checks anyone can run

  • Verify the /owner/programme-uptake 404 link is fixed or still present at HEAD (persona-02). UNKNOWN current
  • Confirm GET /fibre-programs/{id} returns default_reservation_term_months (never positively verified; port-plan.md:80). UNKNOWN
  • Confirm the claim-positions funnel returns data for a participant account on DEV (the 2026-08-03 probe used an account with zero programmes). UNKNOWN
  • Re-verify the Tier 4 home tiles reading 0 vs 274 MT production records (July observation, possibly stale). UNKNOWN
  • Decide the fate of monet’s richer notifications UI (T49 decision-gated regression). STATED