01 · Contribute
Make the floor stronger
Reproduce a failure, add a prevention guard, improve a benchmark, fix a flaky test, or make the docs match the command output. The issue labels name the evidence needed.
Development floor Contributor hub AGPL-3.0
Build the harness.
Break it honestly.
Bridlewise is built in the open, in one repository. Next to the product it carries the tests, prevention guards, benchmarks, decision records, and verification machinery. This page is where contributors start.
Node 24 · Linux first · public gate green · full suite incomplete · not production-ready
Bridlewise is an experimental developer preview. It is not production-ready, and it is not safe for sensitive, proprietary, regulated, or production code. The floor records verification work about Bridlewise. It does not turn Bridlewise into a supported product.
One repository
The product and its floor live together.
One repository, one site, one set of checks. The product is a projection of the same tree, never a second copy.
| Part | What it is for | Start here |
|---|---|---|
main | The source: the product code, its tests, guards, benchmarks, decisions, and evidence records. Every change lands here through a pull request. | Repository · How to help |
product | The shipped tree, projected from main after each land. Releases are tagged on it. | Releases · Quickstart |
| This site | The product documentation and the floor pages, built from docs/ on main. Each release keeps its own documentation. | Product home · Versions |
Three ways in
Contribute. Build. Verify.
Pick the path that matches the work you want to do. Each one starts with a public command, not a promise.
02 · Build
Extend the harness
Add a governed tool, a block, a provider, an MCP server, a quality check, or an embedding. The extension points and typed refusals are part of the shipped tree.
03 · Verify
Check the claim
Run the public gate, inspect the test atlas, read the status snapshot, or rerun an evidence command. A green badge is a pointer, not a proof.
How to help
Useful work, with a visible finish line.
The roadmap is grouped by outcome, not by a wish list. These are the lanes where a contribution can move a milestone.
Reproduce
Turn a report into a failing test
Capture the exact command, the typed error, the run id, and the smallest disposable fixture. Redact secrets and private code. A reproduction is the start of the fix.
Prevent
Add a guard that would have caught it
A prevention guard states the class, the plant, the driven behavior, and the liveness check. It must fail on the old behavior and pass on the fix.
Make it reproducible
Shard, fetch, and merge the floor
The full suite is too slow for one host and too dependent on external fixtures. Help build the shard contract, the corpus manifest, and the single merged receipt.
Build
Extend a real boundary
Provider conformance, MCP transport, platform path handling, quality packs, and embedding contracts are all open work. Add the test at the layer that owns the behavior.
Document
Make the record match the code
Commands, config keys, routes, and user-visible behavior change. The docs and the release evidence must change with them. A broken example is a bug.
Review
Read for the failure mode
Review the owner, the trust boundary, the failure path, and the evidence. A passing run is necessary, not sufficient. Report vulnerabilities privately.
Roadmap
A milestone is a state of evidence.
No dates. Each milestone names what must be true before the next one can be claimed. The full roadmap carries the workstreams and exit criteria.
| Milestone | State | What must be true |
|---|---|---|
| M0 · Public floor online | Done | The public repository, Pages, the public gate, failure reporting, promotion, and a prerelease are live. |
| M1 · Reproducible, sharded floor | Active | A documented full-suite workflow runs on shards, merges into one receipt, and every canonical test file runs once. |
| M2 · Admission evidence | Next | Readiness is reported per capability, with the evidence and remedy attached. A single boolean is not enough. |
| M3 · Product hardening | Next | Backup and restore are one verified flow; provider coverage, portability, scale, and accessibility still need tested failure paths. |
| M4 · Sustainable contribution | Active | A new contributor can go from clone to a merged test or docs change using only public instructions. |
Build on the harness
The extension points are contracts.
The engine is not a closed chat loop. It exposes governed seams, and each seam has a refusal path when it is not configured.
- Tools and blocks. One registry, one executor, typed pre-dispatch checks, and explicit blockers. Add the manifest and the executor together.
- Providers. The Responses path is primary. A Chat Completions adapter is supported where the protocol matches. No universal compatibility claim.
- MCP. Stdio, Streamable HTTP, and WebSocket transports, with Landlock confinement for stdio where the host exposes it.
- Quality and language packs. Typed checks that report findings and deltas, not silent pass states.
- Embedding. The engine barrel is public. The server and cockpit stay separate from domain logic.
Read Building on the harness for the contracts, then add the test at the layer that owns the behavior. The testing guide explains where each test belongs.
First ten minutes
Run the public gate before you change anything.
git clone https://github.com/LLM-4-People/bridlewise-testing.git
cd bridlewise
npm ci
npm --prefix engine ci
npm run bootstrap:hooks
chmod 600 engine/bridlewise.config.json
npm run typecheck
npm --prefix engine run typecheck
npm run test:publicThe public gate is the part that works on a fresh clone. The corpus-backed suites and the live provider suite have named prerequisites and are not silently skipped. Read the testing guide before claiming a full run.
What this site does not prove
Unknown is not green.
- A green public gate is not the full suite. It proves the configured public steps passed at one commit.
- The full suite is not yet reproducible from a fresh clone. The external corpus, the performance report, Chromium, systemd, OpenSSL, and Landlock are separate prerequisites.
- Counts move. The atlas and status snapshot are dated. Treat an old snapshot as history.
- There is no security audit. No third-party review, penetration test, or certification exists.
- The floor is not permission. Do not point the preview at a codebase you cannot lose.