Roadmap: build the floor
This is the engineering roadmap for the Bridlewise development floor: what shipped, what is in progress, what is planned but not done, and the evidence behind each claim. It is a statement of intent with exit criteria, not a release schedule and not a promise that a milestone closes on a particular version. The status blocks are generated from their owners; the prose is hand-written.
Bridlewise is an experimental developer preview. It is not production-ready and it is not safe for sensitive, proprietary, regulated, or production code. A roadmap item is not a security review, a support commitment, or permission to use the preview on code you cannot lose.
At a glance
Where the floor stands
0 of 56 tracked items shipped (0%). The tracked total covers the roadmap’s workstreams and exit criteria and every open tracker item. 7 not-planned statements sit outside it. A close counts as shipped only when linked evidence proves it; a close without proof reads claimed.
0 shipped · 24 claimed, unverified · 0 in progress · 31 planned · 1 blocked · 7 not planned.
Milestones
A milestone’s state is computed from its members: shipped when every planned member shipped (proven), claimed when every member is closed but some only by an unverified claim, in progress when any proven work landed. Shipped and open count the workstreams and exit criteria assigned to it.
| Milestone | Focus | State | Shipped | Open |
|---|---|---|---|---|
| M0 | Public floor online | claimed | 0 | 0 |
| M1 | Reproducible, sharded floor | planned | 0 | 3 |
| M2 | Admission evidence | planned | 0 | 6 |
| M3 | Product hardening | planned | 0 | 9 |
| M4 | Sustainable contribution | planned | 0 | 5 |
Now / next / later
Every open workstream or exit criterion that names a horizon, ordered by horizon, then milestone, then rank. The plan below carries every item.
Status legend
| State | Meaning |
|---|---|
| shipped | The mechanism exists, and its evidence resolves in the public tree or a documented external record. |
| in progress | Work has started; the exit criterion is not met. |
| planned | Named, owned, and not started. |
| blocked | Named and owned, but it cannot proceed until the named condition changes. |
| not planned | A deliberate non-goal, kept here with its reason. |
A milestone’s state is its focus state, not a roll-up of the item states. An item’s state is the row’s own. A status is not a review, a support commitment, or permission to run the preview on code you cannot lose.
Snapshot
This is the dated public-baseline audit. It is a point-in-time record, not a live roll-up of the tables on this page; the status page and the atlas carry the generated, dated evidence.
| Dimension | Current state |
|---|---|
| Latest prerelease | v0.0.3-preview, published through the promotion gate with a receipt and checksums |
| Public gate | Green on both repositories at the recorded commits |
| Public smoke suites | Product 11/11, testing 34/34 (the generated blocks and the tracker are the state of record; this row is a dated audit) |
| Full suite | Supported set green, complete tree still gated. At the 2026-10-20 audit the 521-file supported set passed 8722 tests with 0 skipped, and a clean clone at b866b826 reproduced it with the documented setup (8720 passed, 2 expected, 0 failed). Four named exclusions remain: two private-only guards, the performance regression gate, and the WSL-host keep-out arm. The raw corpus and the performance report are not published; the pinned subset is fetched with npm run corpus:fetch. The supported set has since grown to 523 files and 8734 tests (receipt 39471843640); the status page carries the current dated numbers |
| Full-suite time | The 10-shard ubuntu-24.04 receipt at d47909de measured testPhaseMs 86.7s and testPhaseCpuMs 636.8s: 2.81x the 244.0s single-host supported run. The 10x line is not met on this runner class. This row records that audit; later receipts, including the re-measured shard weights, are on the status page |
| Readiness | Pre-admission. preflight reports harnessReady: false |
| Security review | None |
| Contribution path | Documented in How to help and CONTRIBUTING.md |
The snapshot is dated by the status page and the atlas. This page names the direction; those pages carry the generated evidence.
How to read a milestone
Each milestone below names the problem and the contribution lane. It is rendered from its Milestone item (docs/trackers/items/M0.md … M4.md), the one place its title and prose are written. Its workstreams and exit criteria are rendered under Workstreams and exit criteria from their own items. That keeps every fact in one place.
A milestone is not “done” because a page says so. A close is a claim: an item is shipped only when linked evidence proves it — a decision it carries out is built, its tests exist, its evidence: record is recorded in a tracked manifest, or its evidence is this repository’s own pull request, run or release. A close with no such proof reads claimed, unverified. Each item’s record names where it was carried from, so a plan that was implicit in the old prose remains attributable.
M0 · Public floor online
State: claimed — 0 of 6 members shipped, 6 claimed, 0 in progress, 0 blocked. The record.
Problem: the project needed a public, inspectable development surface without pretending the private corpus, full test floor, or internal evidence could be published as a product.
What exists:
- Two public repositories under AGPL-3.0-only with separate roles.
- A product Pages site and a testing Pages site with a contributor hub, floor console, atlas, evidence, and promotion pages.
- A public gate in both repositories: typecheck, secret scan, public smoke tests, builds, and guardian checks.
- Failure reporting that opens one issue per workflow and branch or pull request, comments on repeats, and closes on success.
- A promotion gate that reads runs at the exact commit, waits for in-flight checks, and emits a receipt.
v0.0.3-preview, published through the gate with checksums and attestations.
Evidence: Floor status · Evidence commands · Promotion contract · Release
Carried from the hand-kept roadmap plan when the roadmap became generated from tracker items.
M1 · Reproducible, sharded floor
State: planned — 0 of 12 members shipped, 9 claimed, 0 in progress, 0 blocked. The record.
Problem: the full suite is not reproducible from a fresh clone, and its wall-clock time does not fit a useful feedback loop. The 4.1 GB corpus and the performance report are external; the supported web suite is already at the physical floor of one 12-core host. The supported public set is now explicit, but the 10x test-phase target has not been measured on a larger runner class.
How the gate works. The shard gate is .github/workflows/test-shards.yml, called as the shards job from .github/workflows/ci.yml on every push and pull request to main, and still dispatchable on its own. The merge job fails the run when a shard fails or when the union of the shard reports does not equal the manifest exactly once, and it uploads test-shard-receipt as the receipt artifact. The ten-shard default on standard runners is a reproducibility path, not a claim of 10x. The workflow accepts a runner label so the measured 10x target can be attempted on a documented larger class. Making the job a required check is a branch-protection setting, not a workflow property.
Help wanted: measure the 10x test-phase target on a documented larger runner class; run an idle-host campaign that makes the CPU-per-file budget judgeable; add a same-commit single-host comparison to the receipt; split a slow test file without changing what it proves.
Carried from the hand-kept roadmap plan when the roadmap became generated from tracker items.
M2 · Admission evidence
State: planned — 0 of 9 members shipped, 3 claimed, 0 in progress, 0 blocked. The record.
Problem: readiness is still described by a single boolean that is false. A boolean cannot say which capability is admitted, what evidence supports it, or what remedy remains.
The receipt shape for each capability is recorded in the task board; the admission gates themselves are open. The plan rows below separate the receipt shape from the gates so a shipped receipt cannot be read as an admitted capability.
Help wanted: readiness receipt design, evidence indexing, release verification, threat-model review, and tests for refusal paths.
Carried from the hand-kept roadmap plan when the roadmap became generated from tracker items.
M3 · Product hardening
State: planned — 0 of 11 members shipped, 2 claimed, 0 in progress, 0 blocked. The record.
Problem: the preview has a supported backup/restore flow for the database and its key material, but limited provider coverage, Linux-only confinement, and no published performance envelope.
What shipped. npm run db-backup -- backup|restore writes a new folder holding a verified database copy, the key material (or passphrase salt) that opens it, and a digest/row-count manifest; it proves the copy opens under that material, and a restore holds the database alone, keeps a verified <db>.pre-restore copy, and proves the restored database opens before calling it done. The flow, its refusals and its limits (the timeline ledger and the pre-migration/pre-rekey copies are not in the bundle) are documented in the CLI reference.
Help wanted: provider adapters, platform probes, benchmark design, and accessibility tests.
Carried from the hand-kept roadmap plan when the roadmap became generated from tracker items.
M4 · Sustainable contribution
State: planned — 0 of 9 members shipped, 4 claimed, 0 in progress, 0 blocked. The record.
Problem: the floor is inspectable, but a new contributor still needs a guided path from clone to a reviewed change. The roadmap and the contribution lanes must be visible without reading internal history.
Help wanted: onboarding tests, issue triage, docs examples, review guides, and translations of the evidence into plain language.
Carried from the hand-kept roadmap plan when the roadmap became generated from tracker items.
Workstreams and exit criteria
The owner of this section is the tracker: every milestone, workstream, exit criterion and not-planned statement is one item file in docs/trackers/items/ (each title below links to its record; the task board lists them all), and every state is computed: a close is the item’s recorded claim, shipped only when linked evidence proves it (otherwise claimed), and every open state comes from what the item is blocked by, its sub-items and the decision records it carries out. Change an item, not a table; npm run docs:roadmap rewrites the generated blocks. Each record says where it was carried from, so a plan that was only implicit in prose is still attributable.
Milestone plan
Each milestone group names its workstreams and exit criteria with the owner, the computed state, the exit criterion and the evidence. Each title links to its record, which carries where it was carried from, its links and its history.
M0 · Public floor online — claimed (0 shipped · 0 open)
Workstreams
| Workstream | State | Owner | Evidence |
|---|---|---|---|
| Public floor, public gate and preview release Exit: Both repositories, the Pages sites, the public gate, failure reporting, the promotion gate and v0.0.3-preview are live. |
claimed, unverified | maintainers | this page: snapshot |
| Build the floor from a clean machine Exit: A clean clone reaches the public gate, the pinned corpus probe, and the supported suite through the documented commands; the sharded gate and receipt (M1), corpus boundary (M1), contributor hub (M4), and remaining known gaps (M2-X4) are composed here rather than restated. |
claimed, unverified | floor tooling | evidence: a-fresh-clone |
Exit criteria
| Exit criterion | State | Owner | Evidence |
|---|---|---|---|
| The clean-machine setup names every build before the suite Exit: The setup sequence names the guardian build and engine bundle before the supported suite, and docs/testing.md names each refusal rather than calling it a skip. |
claimed, unverified | floor tooling | evidence: a-fresh-clone |
| Docs and briefings resolve only to tracked paths Exit: The docs link check resolves every tracked repository-relative Markdown link, and the briefing liveness guard refuses a linked path or backticked repo path that git does not hold. |
claimed, unverified | docs | evidence: docs-links |
| Tracked modes and the self-protection config keep their contract Exit: A tracked file recorded as 100644 stays 0644 in the working tree; a new atomic write takes 0600 only when it creates the file; and engine/bridlewise.config.json is 0600 in the checkout and CI. |
claimed, unverified | floor tooling | TASKS: done |
| Every gate carries a replayable evidence record Exit: The evidence page's gates name a command and an expected shape, and the record-your-own-check form gives a reviewer the claim, commit, command, observation, and interpretation fields. |
claimed, unverified | docs | evidence: record-your-own-check |
M1 · Reproducible, sharded floor — planned (0 shipped · 3 open)
Workstreams
| Workstream | State | Owner | Evidence |
|---|---|---|---|
| Shard the full suite Exit: The manifest verifies against the live suite, the plan is deterministic, and a matrix of runners executes disjoint shards. |
claimed, unverified | floor tooling | evidence: the-sharded-gate |
| One qualification receipt Exit: The merge refuses a missing, duplicate, failed, skipped, dirty or wrong-commit shard and uploads one receipt with the counts, timings and exclusion anchors. |
claimed, unverified | floor tooling | evidence: the-sharded-gate |
| Reproducible fixtures Exit: The pinned corpus subset is fetched and verified outside the checkout; the raw cache stays unpublished. |
claimed, unverified | engine fixtures | evidence: corpus-boundary |
| Reproducible performance report Exit: A profile at the judged head is generated by npm run perf:profile under the idle-host contract and judged by the regression gate. |
planned | performance | evidence: performance-probe |
| Repair the baseline reds Exit: The supported file set runs without a failing or skipped test, and every exclusion is named with evidence. |
claimed, unverified | floor tooling | evidence: the-supported-suite-on-one-host |
| A node:test shard runner that preserves the inventory contract Exit: The public node:test smoke files run inside the same shard and receipt contract as the supported Vitest set, without leaving the inventory. |
planned | floor tooling | evidence: the-sharded-gate |
Exit criteria
| Exit criterion | State | Owner | Evidence |
|---|---|---|---|
| CI calls the shard workflow Exit: A push and pull-request CI job calls the shard workflow; dispatch remains available. |
claimed, unverified | CI | evidence: the-sharded-gate |
| The merge refuses a bad shard set Exit: The merge refuses a missing shard, a duplicate file, a skipped file, a failed result, a dirty tree, or a shard from another commit. |
claimed, unverified | floor tooling | evidence: the-sharded-gate |
| The merge uploads one receipt Exit: The merge uploads one receipt naming the manifest digest, shard indexes and timings, pass/fail counts, and the excluded files with their evidence anchors. |
claimed, unverified | floor tooling | evidence: the-sharded-gate |
| The receipt names commit, class, time and prerequisites Exit: One receipt records the exact commit, shard count, runner class, total test-phase time, and any unsupported suite with its named prerequisite. |
claimed, unverified | floor tooling | evidence: the-sharded-gate |
| 10x test-phase factor on a documented runner class Exit: The full-suite test phase is at least 10x faster than the single-runner baseline on the documented runner class, and the receipt records the measured factor. |
planned | floor tooling | evidence: the-sharded-gate |
| A fresh clone runs the supported suite Exit: A fresh clone with the documented setup runs the supported suite without guessing which tests are silently missing. |
claimed, unverified | floor tooling | evidence: a-fresh-clone |
M2 · Admission evidence — planned (0 shipped · 6 open)
Workstreams
| Workstream | State | Owner | Evidence |
|---|---|---|---|
| Per-capability readiness receipts Exit: Every capability names its gate decision, the policy fact that decided it, and a remedy when denied. |
planned | engine governance | TASKS |
| Close the remaining pre-admission gates Exit: Model invocation, repository mutation, process execution and network egress each have an admission decision or a named refusal. |
planned | engine governance | evidence: what-none-of-this-proves |
| Publish the method and limits of the safety and privacy controls Exit: The detectors, redaction and Landlock boundary are documented with their limits. |
planned | engine safety | evidence: guardian |
| Release provenance and verification Exit: Versioned metadata, checksums, attestations and a verification path ship; signing follows a reproducible build. |
planned | release | evidence: product-preview-release |
| Independent security review Exit: An independent review is commissioned, or its absence is stated without implying that CI is an audit. |
planned | maintainers | evidence: what-none-of-this-proves |
Exit criteria
| Exit criterion | State | Owner | Evidence |
|---|---|---|---|
| preflight names each capability Exit: preflight names each capability and its state, with evidence and a remedy for anything denied. |
claimed, unverified | engine governance | TASKS |
| No admitted capability without a receipt Exit: No capability is described as admitted without a reproducible receipt. |
planned | engine governance | TASKS |
| A release is verifiable from published assets Exit: A release can be verified from published assets and instructions. |
claimed, unverified | release | evidence: product-preview-release |
| The review boundary is stated without an audit claim Exit: The project states exactly what has and has not been reviewed, without implying that CI is an audit. |
claimed, unverified | maintainers | evidence: what-none-of-this-proves |
M3 · Product hardening — planned (0 shipped · 9 open)
Workstreams
| Workstream | State | Owner | Evidence |
|---|---|---|---|
| Backup and restore for the database and key home, with verification Exit: One documented flow backs up and restores the database with its key material and proves each copy opens. |
claimed, unverified | server database | cli: db-backupts |
| Provider conformance fixtures and clearer setup failures Exit: The Responses path and a second provider shape are proved offline, with typed setup failures. |
planned | engine providers | evidence: what-none-of-this-proves |
| MCP coverage Exit: The MCP transports and server lifecycle have conformance coverage and named prerequisites. |
planned | engine MCP | extending |
| Cross-platform path handling with an explicit Landlock refusal Exit: Platform limits are stated before installation, and unsupported confinement refuses explicitly. |
planned | engine platform | evidence: guardian |
| Measured scale and performance envelope Exit: Large repositories and concurrent runs have a measured envelope, and red budgets are tracked rather than called a pass. |
planned | performance | evidence: performance-probe |
| Accessibility and responsive behavior as tested contracts Exit: Accessibility and responsive behavior have tested contracts, not visual claims. |
planned | web | evidence: what-none-of-this-proves |
| A stable extension surface with compatibility notes Exit: Extension points carry compatibility notes and a tested failure path. |
planned | engine extension | extending |
Exit criteria
| Exit criterion | State | Owner | Evidence |
|---|---|---|---|
| Each capability has a failure path and a regression Exit: Each capability has a documented failure path and a regression. |
planned | product | evidence: what-none-of-this-proves |
| Backup and restore are one verified flow Exit: Backup and restore are one documented flow with a verification step. |
claimed, unverified | server database | cli: db-backupts |
| Platform limits are stated before installation Exit: Platform limits are stated before installation. |
planned | engine platform | evidence: guardian |
| Performance claims link to a method and a report Exit: Performance claims link to a method and a report. |
planned | performance | evidence: performance-probe |
M4 · Sustainable contribution — planned (0 shipped · 5 open)
Workstreams
| Workstream | State | Owner | Evidence |
|---|---|---|---|
| A contributor hub distinct from the product home Exit: The floor has its own front door, separate from the product documentation mirror. |
claimed, unverified | docs | index |
| Issue lanes with evidence requirements and a named next action Exit: Every open issue names the evidence it needs or the decision it waits on. |
planned | maintainers | — |
| A first-patch path for docs, tests, guards, benchmarks and portability Exit: Each contribution lane starts from a public command and a reviewable first step. |
claimed, unverified | docs | help |
| Review expectations that reward reproduction and prevention Exit: The review guide asks for the reproduction, the prevention guard and the evidence, not only a green run. |
claimed, unverified | maintainers | CONTRIBUTING |
| A roadmap that records state and exit criteria instead of a wish list Exit: Every planned-but-not-done item is rendered from its owner, and a guard refuses a stale status block. |
claimed, unverified | docs | this page: workstreams-and-exit-criteria |
Exit criteria
| Exit criterion | State | Owner | Evidence |
|---|---|---|---|
| A newcomer can go from clone to a reviewable change Exit: A new contributor can install, run the public gate, pick a labeled issue, and open a reviewable change using only public instructions. |
planned | docs | evidence: a-fresh-clone |
| Every open issue names its missing evidence Exit: Every open issue states what evidence is missing or what decision is needed. |
planned | maintainers | — |
| The roadmap and issue labels agree Exit: The roadmap and the issue labels agree about the current milestone. |
planned | maintainers | — |
| A documented example matches its command output Exit: A documentation example is verified against the command output before it ships. |
planned | docs | evidence: docs-links |
Open work
Everything below is rendered from its owners: the open tracker items (the task board lists them) and the explicit non-proofs of the evidence page. An item leaves the task board only when it closes; a non-proof disappears only when the evidence page stops naming it.
Open task board
Every open tracker item outside the milestone plan appears here, by lane. An item leaves this table only when it closes.
Open
| Task | State | Owner | Evidence |
|---|---|---|---|
| Bring the supported suite under the calibrated-work cap | blocked (blocked by RISK-NO-CALIBRATED-JUDGED-RUN) | — | — |
| No clean judged run in calibrated-work/v1 yet | planned | — | evidence: the-supported-suite-on-one-host |
Flaky burn-down owners
| Task | State | Owner | Evidence |
|---|---|---|---|
| FLAKY-PUBLIC-ENGINE-GUARD-REDS-ON-ROUND-TREES | planned | — | — |
| FLAKY-PUBLIC-ENGINE-UNDIAGNOSED | planned | — | — |
| FLAKY-PUBLIC-ENGINE-UNLOGGED-RECORDS | planned | — | — |
| FLAKY-PUBLIC-S1-B12-CONTROL | planned | — | — |
| FLAKY-PUBLIC-WEB-GUARD-REDS-ON-ROUND-TREES | planned | — | — |
| FLAKY-PUBLIC-WEB-WATCHDOG-C3 | planned | — | — |
Private web lanes (retained as ordinary work)
| Task | State | Owner | Evidence |
|---|---|---|---|
| FLAKY-PERF-GATE-STALE-REPORT | planned | — | — |
What the evidence does not prove
The public evidence page names what its receipts do not establish. These statements are not coverage and not a pass.
Not planned
Deliberate non-goals, kept here with their reason.
| Not planned | Why | Evidence |
|---|---|---|
| Skipping or hiding a failing test to make a badge green | A failing test is owned by a named task row, and a guard refuses a stale duplicate. | TASKS |
| A hosted multi-tenant service in the preview | The preview is a single-user developer preview and carries no hosting claim. | this page: snapshot |
| Publishing the raw 4.1 GB corpus as a repository | Mixed licenses, nested histories, duplicate checkouts and credential-shaped fixtures. | evidence: corpus-boundary |
| A production-readiness claim before the admission evidence exists | The admission gates are open and no capability beyond preflight is admitted. | evidence: what-none-of-this-proves |
| A release date | This roadmap is a statement of intent, not a schedule. | this page: snapshot |
| A universal provider compatibility claim | Provider conformance is proved per shape, not universally. | extending |
| A benchmark number without its method | Performance claims must link to a method and a report. | evidence: performance-probe |
How this roadmap changes
A milestone, workstream, exit criterion, not-planned statement or task changes in its item file under docs/trackers/items/ (the task board and this page are both rendered from them); a non-proof changes in the evidence page. Then run npm run docs:roadmap to rewrite the generated blocks. npm run docs:roadmap -- --check is the read-only form.
The generated blocks are not hand-editable. The site build also refuses a page whose emitted classes have no rule in the shared stylesheet (npm run design:coverage), and a built-page assertion checks that this page’s tables are tables rather than paragraphs, so a generator change that breaks rendering fails the deploy rather than the reader. A guard (tests/prevention/roadmap-status-owner.test.ts) fails when the page differs from the renderer’s output, when an open roadmap item names no milestone, or when an item’s evidence points at a missing file or anchor.
The decision records hold the durable reasoning. The status page holds the generated snapshot. This page holds the direction and the plan. If an item is blocked, its row says so. A visible block is better than a quiet omission.