Product Roadmap

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?

Future feature: implement real dark mode — a .dark design-token set, a theme provider + toggle, and fixing the ~32 hardcoded bg-white surfaces so they theme correctly. Decision 2026-07-05: deferred; for now the dead, never-activated dark: scaffolding is being removed under UX-FIX-02.

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.

A module that takes a set of answered questions and wraps them into a report, following a report definition. The diagnostic is definition one; investment readiness is definition two; there is no upper bound. The report is not a diagnostic feature - it is a module the diagnostic happens to use first. THREE BUILDING BLOCKS 1. Question - one question, its evidence table with references in the cells, its conclusion and recommendation. Universal. 2. Hypothesis - its questions in order, plus a cross-question conclusion and the verdict. Universal. 3. Report type - which hypotheses, the across-hypothesis sections (SWOT, challenges, strategic direction), the front matter, and the colour, style and rules. The only layer that varies. Blocks 1 and 2 are machinery. What varies is which ELEMENTS they emit, and that is configuration: a question carries a conclusion and a recommendation today; another report type could swap the recommendation for a financial implication. Element content is stored by name, never in a column, so a new report type is configuration, not a database change. ONE QUESTION, ONE SECTION, ALWAYS. The consultant adds or removes questions before finalising. This removes the one risk the methodology called uncheckable: an AI deciding which findings sit together. REFERENCES ARE A LOOKUP. The Excel register numbered findings F001/DF231 because a spreadsheet cannot point at a row. Our database can. Proven on live data: a 12-row table, 5 verified receipts, 124 source rows, one named document. SPEC: docs/requirements/REPORT_Reporting_Module.md PROOF: scripts/_oneshot_report_unit_slice.ts - one complete unit from prod, zero AI calls. BUILD ORDER: 1 complete the register · 2 block 1 · 3 block 2 · 4 block 3 · 5 Word and PDF styled by the definition · 6 bulk answering. BLOCKED ON: AI account credit. See also ENG.ERRORCAUSE.

Chapters 7 and 8 stop being written and start being calculated. Every action on the roadmap carries what it is expected to produce and what it costs, so the business plan is the sum of the actions you actually recommended rather than a separate piece of writing. You state one assumption in plain terms - two new clients a quarter, each worth about 15,000 - and everything after it is worked out from figures already in the register: the annual value, the materials, what is left. Change the assumption to five clients every two months and the whole chapter follows instantly, at no cost. Assumptions say what they rest on: the company's own history, outside evidence, or your experience. The ones resting on experience are marked, and the chapter states how much of the plan is standing on them, so you can see exactly which line to sharpen first. Actions that genuinely earn nothing, like documenting procedures or working on the team, say so and are counted as cost rather than given an invented benefit.

The platform already notices when two documents disagree on a NUMBER. It could not notice when they disagree on a MEANING. On a real engagement one account was filed as income from a government subsidy programme when it was in fact a VAT invoicing rule - every figure was correct, so nothing was flagged, and the wrong explanation stayed in the delivered report through three versions. Now, when a newly filed document describes a concept the platform already knows in a way that contradicts what it was told before, it raises it for review alongside the numeric disagreements. It only compares definitions of the same concept from different documents, and it stays quiet when the second document merely adds detail or covers a different period.

The engine was overpaying for its own reading material: before every answer the planner re-sends its 54,000-word rulebook, and the vendor's 5-minute discount cache expired between battery questions (3-8 min each), so nearly every question re-paid the full price. The July spend audit showed this was ~2/3 of the recorded API bill. What changed: 1. Planner + reviewer rulebooks now park in the 1-hour cache - one payment per battery instead of one per question. Proven live: a repeat question 7 minutes later re-read all 80,976 rulebook tokens free; repeat planner cost fell ~$0.51 to ~$0.05. Expected: roughly 30-40% off every battery run. 2. The spend ledger's price list was missing the planner's pinned model, overcharging it ~67% on paper and tripping the $100/day cap early. Fixed - ledger and cap now reflect reality. 3. Three diagnostic AI calls (hypotheses, research questions, data gaps) ran invisible to the ledger and daily caps. Now counted, capped and priced. 4. Test runs now label their own spending (was "unknown" on 98% of rows), so cost audits are one query and the per-client cap covers scripted runs too. 5. Bonus fix, found when the API wallet hit $0: consultants used to see "I couldn't pin your question to a tab" - a billing outage disguised as missing data. Now the answer says the AI service is unavailable and the data is fine. (Delivers the billing slice of the parked ENG.ERRORCAUSE card.) Verified through the engine unlock protocol (QA-55 in the campaign ledger): full unit sweep (3,978), 52/52 exact replay, live two-run cache proof, and the 10-question smoke matching the accepted certification pattern - zero wrong numbers. Four commits on release/next.