Everything Fulltrace might do next, run as a queue rather than a wish list. Every idea becomes a row in the register with an ID, a risk class, and the guardrails it must respect, and nothing gets built without one. The standout tracks are below, then the full live register. How a row becomes shipped software is the workflow page; what already shipped is the build log.
The register does not rank by excitement, but this page can. What is queued next, and the tracks that change what Fulltrace is.
The injection fence is built and switched on: audited content is treated as data, never instruction. What is left is proving it costs nothing on the content side. Run a real content and website audit through the fenced path and check it against the pre-fence baseline: findings depth, every anchor still resolving, and the verbatim-copy contract surviving source fencing, with the spend bound set before it starts.
The same check on the code side already came back clean: three targets, about US$0.32 in spend, no quality regression. This content-path check was blocked behind hardcoded drive letters that broke the full test suite, now cleared. A shipped defence with one unverified path is a defence with an asterisk, and this row exists so the asterisk cannot be quietly forgotten.
A Studio chat tab under the same guardrails as everything else: explicit pick, vendor-pinned auto, or full Auto through a two-stage router, with metered API calls and subscription CLIs as parallel execution classes. The design is shipped and adversarially reviewed, with the build cut into four slices.
Push notifications and a read-only mobile triage page over the tailnet already work. The next step is the first off-machine write: approve or reject an inbox item from the phone, issuing the same grant through the same path as the desk.
The system runs scheduled work on its own: schedule, enqueue, auto-drain. Arming a schedule is a recorded act bound to its content hash, so any edit disarms it until it is re-approved, and a decision-debt cap stops it generating decisions faster than I can review them.
Several machines, each running its own copy, push what they are doing to one place I can watch. That place can only look: it never approves, never applies, and holds no authority channel back to a node, a fleet I can watch but never command. The design is shipped, after two external adversarial reviews, with the build cut into four rows behind it.
A five-model Ollama fleet, running on my own machine, costing nothing per use, observed and warmed from Studio > Models. The sequencing is the point: execution-class recording (metered, subscription, local) shipped before the fleet surface existed, so no local call could ever have gone unrecorded. Pipeline participation is refused outright in v1 and gated behind its own design row, rather than allowed by default just because it is free.
A browser page that can make changes, wrapped in the same freeze, simulate, approve, apply spine as everything else. Even localhost is treated as hostile-caller territory: a link opened off-machine can reach a read-only triage view at most, never the write API.
Mine run metrics, dispositions, and verifier verdicts for per-workflow signal, then feed it back into prompt, model, and route selection. Descriptive first: nothing changes agent behaviour without its own gated slice.
A code-owned registry of every user-state domain: settings, target registries, memories, skills, commands. Exports to a git-tracked repo with a fail-closed secret scan before anything leaves the machine. Config can narrow the export, never widen it.
Every audit gets the same server-owned slice of my working context: no default slice, no client-picked files, and every use of it traced in the report's evidence. It is the first concrete step towards the system remembering context between runs: memory informs, the spine still decides.
Quality per workflow measured on a fixed task set with bounded spend and a results ledger. Which model actually audits better, with receipts.
All 44 live rows, straight off the steering board. Role says why a row exists: boundary rows lock or open a constitutional line, keystones are load-bearing, unlocks enable a later step, hygiene keeps the runtime honest. Risk sets how much design happens before code. Shipped rows leave this table at closeout: 34 so far, narrated in the build log, so a prereq you cannot find below has already shipped.
| ID | Title | Role | Risk | Prereq | Status |
|---|---|---|---|---|---|
| 5P.1 | Browser-on-node operate surface: design gate | boundary | R4 | none | in progress |
| 5O.5 | Injection fence content-path before/after live check | validation | R3 | none | up next |
| 5O.4 | Injection fence red-team eval corpus | validation | R1 | none | proposed |
| 5N.1 | Decision inbox: the "what needs me" projection | keystone | R0 | 5Q.4, 5Q.5 | deferred |
| 5W.2 | Chat tab v1: explicit pick, metered class | unlock | R3 | 5W.1 | proposed |
| 5W.3 | Subscription execution class for chat | unlock | R3 | 5W.2 | proposed |
| 5W.5 | Model provenance in authority-plane records | boundary | R1 | none | proposed |
| 5W.4 | Tiers and Auto routing for chat | boundary | R3 | 5W.3, 5W.5 | proposed |
| 5V.4 | Remote decision surface: design gate | boundary | R0 | 5V.2, 5V.3 + demonstrated demand | proposed |
| 5X.4 | Local provider seam, v1 pipeline refusal, route validation | boundary | R1 | 5X.3 | proposed |
| 5X.5 | Chat local execution class | unlock | R3 | 5W.2, 5X.4 | proposed |
| 5X.6 | Embeddings capability design | unlock | R0 | 5X.4, 5O.2 | proposed |
| 5X.7 | Local pipeline participation design | boundary | R0 | 5X.4 | proposed |
| 5G.1 | Unattended operation design: schedule, enqueue, auto-drain | boundary | R0 | none | proposed |
| 5G.2 | Unattended operation implementation | unlock | R3 | 5G.1 | proposed |
| 5G.3 | Schedule controls in Studio | unlock | R4 | 5G.2 | proposed |
| 5Q.2 | Node identity and origin stamping | keystone | R1 | none | proposed |
| 5Q.3 | Testimony contract and payload shaping | unlock | R1 | 5Q.2 | proposed |
| 5Q.4 | Push publisher | unlock | R4 | 5Q.3 | proposed |
| 5Q.5 | Centre v1: enrolment registry, ingest, observatory | boundary | R5 | 5Q.3 | proposed |
| 5R.1 | Declarative workflow authoring design | boundary | R0 | none | proposed |
| 5S.1 | Portfolio context serve: slice registry and gateway endpoint | keystone | R2 | none | proposed |
| 5S.2 | Runner context module and content-audit migration | unlock | R1 | 5S.1 | proposed |
| 5S.3 | Code-audit executor and challenger voice slices | unlock | R1 | 5S.1 | proposed |
| 5S.4 | Studio context strip and degraded warning | polish | R2 | 5S.2, 5S.3 | proposed |
| 5T.1 | User-state registry and scheduled backup design | boundary | R0 | none | proposed |
| 5T.2 | Backup implementation and Settings tab controls | unlock | R4 | 5T.1 | proposed |
| 5M.1 | Workflow self-improvement from run data: design | boundary | R0 | 5H.2 | proposed |
| 5B.1 | Model evaluations and benchmarks design | validation | R0 | none | proposed |
| 5C.1 | Projects tab design, onboarding interview first | unlock | R0 | none | proposed |
| 5D.1 | Slack outbound notifications design | unlock | R0 | none | proposed |
| 5E.1 | Goals interface design | unlock | R0 | none | proposed |
| 5J.1 | Studio UX review and IA redesign | unlock | R0 | none | proposed |
| 5J.2 | IA restructure implementation | unlock | R2 | 5J.1 | proposed |
| 5J.3 | Run-completion notifications in the IDE | polish | R2 | none | proposed |
| 5J.4 | SSE live updates in Studio | unlock | R2 | none | proposed |
| 5J.5 | Open-source jump in the content-audit panel | polish | R2 | none | proposed |
| 5A.2 | Webview render harness: state-to-HTML snapshot tests | hygiene | R1 | 5A.1 | proposed |
| 5A.3 | Tier 1 extraction: sensitive pure helpers | hygiene | R1 | 5A.1 | proposed |
| 5A.4 | Tier 3 webview decomposition | hygiene | R2 | 5A.2, 5A.3 | proposed |
| 5I.2 | Register drift check | hygiene | R1 | none | proposed |
| 5K.5 | Remaining machine-path pins outside the suite | hygiene | R1 | none | proposed |
| 4G.6 | Studio launch of the website-audit graph | unlock | R2 | none | proposed |
| 4E.30 | Ledger enrichment design: category, type, anchor context | unlock | R0 | none | proposed |