Product Roadmap

[Full audit 2026-09-05, intake engine, finding A1-17 and A1-21, docs/audit/2026-09-05/intake.md] A document's knowledge-base status is set to live in exactly one place: an operator-run repair script. No successful upload sets it. The pill states "sending", "adding" and "ready" are unreachable, because the only function that writes them is called from one place, the stuck-document watchdog, and only to write a failure. Ran on prod: all 168 documents read not_sent, none live, none processing, and 147 of them have live filed tables. The data is in and the product never says so. Local returns 961 not_sent, 65 failed, 1 pending, zero live. The second half follows. The watchdog marks any document sitting in "processing" for over fifteen minutes as failed, telling the consultant it waited too long and we stopped trying. Nothing in the ingest path bumps the timestamp while a run is under way, and a large workbook is filed table by table, four at a time. That timer cannot fire today only because nothing sets "processing"; wire the status and a long upload can be killed while still running. What should happen: a document that filed at least one table, or finished the prose route, is marked ready at the end of its run, and a run in progress bumps its own timestamp so the watchdog only catches dead work. Proposed change: station worker. Files: data-room.ts (report the state at the tail of a successful run), the handoff bridge, the per-table pipeline (bump the timestamp per filed table), the watchdog. Size S. ENGINE LOCK: no for the status writes, yes for the heartbeat. Why a consultant cares: he cannot tell from the product whether a file he uploaded is answerable. Verdict: A1-17 CONFIRMED and stronger than reported (prod: 168 of 168 not_sent, 147 with live tables). A1-21 is a latent risk only, unreachable until A1-17 is fixed, which is why the two ship together.

PRE-MERGE / PRE-LAUNCH GATE. Captcha protection was turned OFF in Supabase (Auth → Attack Protection) on 2026-07-07 so Dancho could test signup without the Turnstile friction. DO THIS WHEN MERGING release/next → main (i.e. before real users): (1) turn Supabase captcha protection back ON; (2) fix the underlying bug — NEXT_PUBLIC_TURNSTILE_SITE_KEY in Vercel is marked "Sensitive", so Vercel withholds it from the build and it is never inlined into the client bundle → the Turnstile widget never renders → "no captcha_token found". A public site key must NOT be Sensitive: un-flag it, re-enter the value from Cloudflare, keep Production+Preview, redeploy. Affects production too. | fix/med | Acceptance: captcha ON in Supabase, widget renders, and a real signup completes on main/prod.

DECISION CARD - educates the call, nothing is built yet. Full brief: docs/decisions/0007-company-biography-layer.md in the repo. THE QUESTION: should the engine keep a standing written story per client company (the "biography"), under the register, separate from it? WHAT RESEARCH FOUND (2026-08-15): the company profile already exists (sector, business model, about - written at client creation) but the answering planner and the report composer NEVER see it; the planner does not even know the client name. Standing client facts are being added piecemeal after every real failure (default currency, fiscal year, label translations) with no unified home. But: only 1 of ~12 eval failures was biography-shaped, our 27-playbook prose experiment moved nothing, stored prose cannot be reconciled and risks becoming a competer, and there are no live clients yet. OPTIONS: (A) three cheap wires now - feed the existing profile into planner + report composer with post-engagement refresh; give durable business-model lessons (the Upwork case) a home as citable facts; compute any cross-document company view on read, never store it. (B) full biography layer now - rejected by the evidence at current scale. (C) do nothing - leaves the profile unread and the Upwork-type knowledge homeless. REVISIT-B TRIGGERS: licensed consultants who do not personally know the client are delivering; returning clients start second engagements. If built then: regenerated from evidence, never hand-maintained. DANCHO DECIDES: 1) do the three A-wires go on the roadmap now? 2) does folding register lessons into standing client facts become part of engagement close? 3) does biography-as-regenerated-artifact get a parked card with the two triggers?

A dedicated session that runs the engagement learning path (PFX-13) over Dancho's 6-8 completed client folders. Per folder: convert the .docx artifacts to markdown, classify the layers (raw-data notes / data register / diagnostic report), run scripts/_oneshot_engagement_learn.ts with a neutral label (eng-YYYY-NN, never the client name), review the candidate packet, land the keepers as drafts, and measure the playbook candidates with the eval harness (PFX-11) before any promotion. The output across all folders: a batch of measured, BizzBee-craft draft skills + recipe candidates + presentation earmarks, and a review-log entry per folder. Dancho promotes; nothing auto-activates. Prerequisite: Dancho shares the client folders. --- Parked 2026-07-11 (queue sweep): needs Dancho to point at the 6-8 client folders, plus a supervised run with an agreed AI-processing budget. Ready to run as a dedicated session.