Decisions

The ONE home of every user rule and every decision in force: one file per decision, found by name and cited by id, never only in a scratch plan. Other documents link a decision by its id instead of restating it.

Each file opens with a front matter:

id — the id the plan and the specs cite (D-04, D-R1, UD-C1, U2); the file is named <id>-<slug>.md; covers lists the further ids a file answers for (a group of accepted recommendations);
date, by (user or coordinator);
group — the section of the index below it is listed in (DECISION_GROUPS in the checker);
status (in-force or superseded, with superseded_by: a chain of supersessions ends at a decision in force); overrides names the decisions a newer one overrides in part;
implementation — standing (binds all work), pending (with route, the task that carries it out), partial (with route and acted_in) or done (with acted_in, the repository paths where it was carried out, held by git in the commit that writes them).

The one checker is engine/scripts/verification/tracker-entries.ts (tests/prevention/decisions-format.test.ts runs it; tests/prevention/agent-docs-liveness.test.ts checks that the paths and commands these files name exist; the commit door judges the acted_in paths of every decision a commit writes).

How far each decision is built is drawn on the development floor, counted from these files when the site is built.

The index below is GENERATED from the files’ front matter and titles by harness sync (engine/scripts/verification/decision-index.ts; harness check reports it stale): change a decision’s file, never its row.

User rules (standing)

Id	Decision	By	State
BE-PROACTIVE	Be proactive: apply principles broadly	user	standing
BUILD-ITERATE-REUSE	Build, iterate, reuse and improve	user	standing
DESIGN-SYSTEM	One design system across the harness	user	pending (DESIGN-SYSTEM)
EXEC-MODES	Everything is blocking, non-blocking or auto	user	pending (MODES)
EXPOSE-MODES	Expose everything; modes for every choice	user	pending (MODES)
FEW-TOOLS	Few tools, each backed by one harness owner	user	pending (TOOLS-FEW)
HARNESS-DRIVES	The harness drives; the model is the passenger	user	pending (GIT-AUTO)
LANGUAGES	TypeScript and Rust only; port by measurement	user	pending (NATIVE-ONE)
MIN-DEPS	Minimal external dependencies	user	standing
NO-BRANDED-NAMES	No branded module names; no needless packages	user	standing
NO-OVER-ENGINEER	Don’t over-engineer; novelty is not a goal	user	standing
ONE-IMPL-PROBE	One implementation for every platform: probe, don’t branch	user	standing
PARTIAL-FAILURE	Partial failure in every tool	user	pending (TOOLS-FEW)
QUALITY-PRINCIPLES	The universal quality principles	user	standing
REC-DIR	Useful work lives in the repository	user	done
RULES-ENFORCED	Rules are mechanically enforced whenever possible	user	standing
SANDBOX-ALWAYS	Everything runs in the sandbox	user	pending (ST-1)
TESTS-TEST-THEMSELVES	Tests test themselves	user	pending (TTT)
UR-01	Shared owners, one source of truth	user	standing
UR-02	Generated values come from generators	user	standing
UR-03	Caching never sacrifices a harness function	user	standing
UR-04	Shared and reusable, backend and frontend	user	standing
UR-05	Expose settings, signals and actions	user	standing
UR-06	Every round’s friction becomes tooling	user	standing
UR-07	Secrets from the environment only	coordinator	superseded by D-09
UR-08	Everything goes through central logging	user	partial (RC-06)
UR-09	Independent verification before every commit and push	user	standing
UR-10	One writer per repository	user	standing, amended by UR-23
UR-11	Research whenever you are not certain	user	standing
UR-12	The product branch changes only through the promotion door	user	standing
UR-13	Provider deviations live in a versioned provider profile	user	pending (RC-08)
UR-14	The continuation mandate: never stop	user	standing
UR-15	Coordinate through delegated agents	user	standing
UR-16	One thing for everything	user	standing
UR-17	No fallbacks	user	standing
UR-18	Every issue class found gets a mechanical guard	user	standing
UR-19	Every rule is retroactive	user	standing
UR-20	Tests are always broad	user	standing
UR-21	Secrets and personal data are redacted, never a reason to block	user	standing
UR-22	The coordinator’s record lives on the coordination branch	user	standing
UR-23	A web writer may work beside the engine writer	user	standing
UR-24	Zero new failures, and every remaining failure owned by a named task	user	done

Process decisions (coordinator)

Id	Decision	By	State
ADDED-CONTENT	A commit never publishes a host	coordinator	partial (GH-537)
D-09	Agents never write a credential into a record	coordinator	standing
D-10	Which record wins	coordinator	standing
D-11	Isolation tooling: one workspace tool	coordinator	partial (A5-CANDIDATE-RETIRE)
D-12	The timeline drops HMAC signing; encryption at rest stays open	coordinator	partial (REQ-025)
D-13	Inherited web reds: the choices	coordinator	partial (PROMO-0)
D-14	Test-drive fixes: detector families and the context budget	coordinator	pending (RC-04), amended by U3
D-15	The database key lives outside the state root; secret files are read redacted	coordinator	done
D-16	undici is the outbound door’s one dispatcher	coordinator	done
D-17	Measured budgets come from their measuring tool	coordinator	partial (A4-OWNED-BUDGET)
D-18	The key scan registers; it never relocates other installs	coordinator	standing
D-19	A process’s temp root lies outside the safety floor	coordinator	done
D-20	Tooling that produces a committed artifact lands with it	coordinator	standing
D-W4	The server-side scale items belong to the web writer	coordinator	standing
D-W5	Mock-free test files share a process	coordinator	pending (WEB-EFFICIENCY)
EVD-STORE	Code and small records in git; raw evidence in a content-addressed store	user	partial (EVIDENCE-DURABILITY)
FLAKE-REPRO	A flake cause needs a recorded reproduction	coordinator	partial (FLAKE-REPRO-REDECLARE), amended by NO-LOAD-BLOCK
GEN-AGGREGATES	No generated aggregate that two independent changes both rewrite	coordinator	partial (GH-563)
INSTRUMENT-LOCK	The host has one instrument lock	coordinator	superseded by NO-LOAD-BLOCK, amended by NO-LOAD-BLOCK
KILL-OWNED-ONLY	Signal only what you started	coordinator	done
LIVE-SUITE	One live suite; the hermetic suites have no skips	coordinator	done
NO-LOAD-BLOCK	Nothing is ever blocked by CPU load	user	partial (TEST-10X)
Q-TX1	A deterministic test file’s result may be reused	user	pending (TEST-10X)
Q-TX2	Test budgets count CPU work, not wall time	user	partial (TEST-10X)
Q-TX4	Every test file has its own budget	user	pending (TEST-10X)
REQUIRES	A gate runs after the steps that produce what it judges	coordinator	done
TEST-CPU-CLASSES	Per-test limits are CPU-work classes plus one hang backstop	coordinator	done
TEST-EFF	The test-efficiency decisions (covers Q-TXL1, Q-TXL2, Q-TXL3, Q-TXL4)	user	pending (TEST-10X)
UD-AUDIT-NO-FORGIVENESS	No rerun forgiveness, no ambient-load allowance	user	done
UD-CORE-NO-BYPASS	A module cannot bypass core	user	pending (CORE-NO-BYPASS)
UD-LOG-NEVER-DISABLED	Logging is never disabled	user	done
UI-CPU	Browser speed gates are judged in CPU work	user	pending (UI-CPU)
UR-24-BUDGETS	A budget breach joins the one judgement	coordinator	done

Earlier engine decisions (coordinator)

Id	Decision	By	State
D-04	Logging migrates in place under a ratchet	coordinator	pending (RC-06)
D-05	A sub-agent resolves its own model or refuses	coordinator	pending (RC-28)
D-06	No dead retry configuration	coordinator	pending (CFG-3)
D-07	An undeclared function call is a recoverable refusal	coordinator	pending (RC-29)
D-08	Background mode only where the provider declares it	coordinator	pending (RC-43)
GUARD-F5	A link under the keep-out floor is kept out by what it names	coordinator	partial (KEEP-OUT-HARDLINKS)

Prompt cache

Id	Decision	By	State
D-R1	A stable tool superset with a gate refusal	coordinator	superseded by U2, amended by U2
D-R2	The workspace snapshot is frozen per chat	coordinator	superseded by U1, amended by U1
D-R3	The trim target defaults to 0.5	coordinator	pending (RC-40)
D-R4	The prompt-cache layout	coordinator	pending (RC-39)
U-REASONING	Provider profiles declare the reasoning replay mode	user	pending (RC-38)
U-X	The cache items that lose no function (covers X1, X3b, X4, X5, X7, X8b, X9b, X11b, X12, X13)	user	pending (RC-39)
U1	Workspace awareness: the snapshot plus a live delta	user	pending (RC-41)
U2	Switched-off tools	user	pending (RC-42)
U3	Large payloads stay abridged and retrievable	user	pending (RC-03)
U4	Recall excludes only retained runs	user	pending (MEM-5a)
U5	The project is derived from the chat	user	pending (MEM-2)
U6	Project-scoped recall plus an opt-in user memory tier	user	pending (MEM-8)
U7	Segment summaries with a recent-turn floor	user	pending (RC-40)
U8	The tail is appended when it changes	user	pending (RC-44)
U9	The context budget is a ratio of the model window	user	pending (RC-12), amended by Q11

Configuration, prompts and credentials

Id	Decision	By	State
CFG-DIR	Configuration is a code registry plus the database	user	pending (CFG)
CRED-DIR	Credentials the model never sees	user	pending (CRED)
CRED-EXFIL	Exfiltration control starts with per-use approval	user	pending (CRED)
CRED-UD-1	Pasted secrets are vaulted automatically	user	pending (CRED-6a)
CRED-UD-3	The exposed tier never ships	user	standing
UD-C1	The most specific scope wins	user	pending (CFG)
UD-C9	Prompts live in a versioned prompt registry (covers PRM-DIR)	user	pending (PRM-0)
UD-CFG-CRED	The configuration and credential designs’ recommendations (covers UD-C2, UD-C3, UD-C4, UD-C5, UD-C6, UD-C7, UD-C8, UD-C10, UD-C11, UD-C12, UD-C13, UD-R2, UD-R4, UD-R5, UD-R6, UD-R7, UD-R8, UD-R9)	user	pending (CFG)
UD-P	The prompt registry’s design choices (covers UD-P1, UD-P2, UD-P3, UD-P4, UD-P5, UD-P6, UD-P7)	user	pending (PRM-0)

Promotion

Id	Decision	By	State
PROMO-AUTO	Auto-promotion is on	user	superseded by PROMO-GH
PROMO-DIR	Promotion is a generic, hands-free primitive	user	pending (PROMO-0)
PROMO-FIRST	The first promotion: reviewed by the user, then applied	user	done
PROMO-GH	The product is promoted in the one repository, on every land	user	pending (GH-5)
PROMO-UD	The promotion design’s choices (covers PROMO-UD-1, PROMO-UD-2, PROMO-UD-3, PROMO-UD-4, PROMO-UD-5, PROMO-UD-6, PROMO-UD-7, PROMO-UD-8)	user	pending (PROMO-0)

The Responses sequence

Id	Decision	By	State
Q-ACCEPTED	The Responses plan’s recommendations (covers Q1, Q2, Q4, Q5, Q7, Q8, Q10, Q12, Q13, Q14, Q15, Q16, Q17, Q18, Q19)	coordinator	pending (RC)
Q11	45% of the model window everywhere	user	pending (RC-12)
Q3	A hardened log file sink	user	pending (RC-06)
Q6	Module versioning follows the third checkpoint	user	pending (MV)
Q9	The test-drive budget	user	standing
RC-AMEND	The spec amendments’ open points	coordinator	pending (RC)
RC-DIR	The Responses API everywhere, driven against a real provider	user	pending (RC)
UD-AUDIT-ROUTING	Provider failover is explicit routing	user	pending (RC-ROUTING)

Scale

Id	Decision	By	State
SCALE-AGENTS	Capacity counts every agent, sub-agents included	user	pending (SCALE-6)
SCALE-DIR	The server easily carries 200 active conversations, then goes further	user	pending (SCALE)
UD-S1	Per-call ledger rows stay; performance is pushed instead	user	pending (SCALE-2a)
UD-S10	Each gate’s mixed run delegates 25% of turns, three wide, two deep	coordinator	pending (SCALE-0)
UD-S11	Delegation depth defaults to 8	user	pending (SCALE-6)
UD-S12	New events’ chain envelope covers a documents digest	user	pending (SCALE-2b)
UD-S15	The fixture chats leave the real database, archived first	user	done
UD-S2	A ledger shard per project, each with its own writer	user	pending (SCALE-3b)
UD-S3	Logs are never lost: segment and archive, never delete	user	pending (SCALE-9)
UD-S4	As high as possible, with no hard ceilings	user	pending (SCALE-5)
UD-S5	Ledger volume falls losslessly, not by compression alone	user	pending (SCALE-2b)
UD-S5b	Hot lean rows, sealed compressed archive, queue on low disk	user	pending (SCALE-2b)
UD-S6	The shard grouping default is one shard per project	coordinator	pending (SCALE-3b)
UD-S7	Every shard is sealed with the web database’s key	coordinator	pending (SCALE-3b)
UD-S8	The existing ledger stays in place	coordinator	pending (SCALE-3b)
UD-S8b	The legacy shard keeps memory storage as it is (replaced)	user	superseded by MEM-DIR
UD-S9	It cannot crash: fix the actual causes; durability before effect	user	partial (SCALE-IE)
UD-S9b	Durability defaults per class; tools fail closed; fail-stop and restart	user	partial (SCALE-IE)

Memory layers

Id	Decision	By	State
MEM-DIR	Continue the memory-layers lab, then build its proven designs on the lean ledger	user	pending (MEM)
MEM-EXCL	The memory layers are off-limits (lifted)	user	superseded by MEM-DIR
MEM-SIZE	Find further lossless memory size reductions	user	pending (MEM-LAB-SIZE)
U-M-GLOBAL	A global memory layer of harness knowledge, admitted by checks and two-person admin approval	user	pending (MEM-LAB-M5)
U-M1	Project memory lives in its project shard, user memory in a per-user shard	user	pending (MEM-3a)
U-M2	Forgetting destroys a key: memory references the ledger, under per-conversation keys	user	pending (MEM-6)
U-M3	The memory capacity floors are proven on this host, within about 100 GB	user	pending (MEM-LAB-M10)
U-M4	Memory placement is chosen from measured precision, within $20 of Coral	user	pending (MEM-LAB-M4)
U-M5	The memory index is int8 vectors with certified exact rescoring, plus a keyed lexical index	user	pending (MEM-5a)
U-M6	No interim patches to the old memory path	user	standing
UD-MCP-MEMORY	MCP tool outputs can live in the memory layer	user	pending (MEM-6)

Labs (docs, browser, intelligence)

Id	Decision	By	State
BL-DIR	Finish the browser-integration lab	user	pending (BL-R1)
BL-GPU	The app runs with no GPU process	user	pending (BL-GPU)
BL-RES	What the browser lab may use: “everything needed”	user	standing
BL-U1	The app, the docs and the server are separate packages	user	pending (BL-R3)
BL-U2	The docs compiler graduates as the bridlewise-docs package	user	pending (PKG-1)
BL-U3	The lab app is re-baselined onto testing once, after its stage is sealed	user	pending (BL-R2)
BL-U4	Seal the fifty-stream stage, plus one 200-stream run	user	pending (BL-R1)
D-W1	The replica key is server-held	user	pending (WEB-EFFICIENCY)
D-W2	A deduplicated, compressed replica of 256 MiB	user	pending (WEB-EFFICIENCY)
D-W3	Offline is read-only, with a banner	user	pending (WEB-EFFICIENCY)
D-W6	A remote action shows a named in-flight row	user	pending (WEB-EFFICIENCY)
INTEL-DIR	Integrate the proven intelligence-codegraph improvements	user	pending (INTEL-TRANSFER)
LAB-UD	The docs-writer lab’s decisions (covers LAB-D1, LAB-D2, LAB-D3, LAB-D4, LAB-D5)	user	pending (LAB-6), amended by BL-U2
PROTO-ONE	One protocol, local or remote	user	pending (AC-7)
UD-ONE-PARSER	One parsing owner for every consumer	user	pending (INTEL-L0)
UD-UI-LOCAL-FIRST	Every click within ten milliseconds: a local-first UI	user	pending (WEB-EFFICIENCY)

GitHub

Id	Decision	By	State
GH-A	Public by default	user	standing
GH-B	Agents act only through least-privilege GitHub Apps	user	pending (P3.9)
GH-C	All labs merge into the one repository	user	pending (P9.1)
GH-IDENTITY	An agent commit carries no personal identity	coordinator	partial (P3.2)
GH-KEYS	GitHub App private keys have one custody: the key home, or a protected environment	coordinator	partial (P1.2)
GH-PROJECTION	GitHub always reflects the harness	user	partial (P5.2)
GH-U	The accepted GitHub recommendations (covers GH-U1, GH-U3, GH-U4, GH-U5, GH-U6, GH-U7)	user	pending (P3.2)
GITHUB-200	Use GitHub fully, and make progress public automatically	user	partial (P5.3)
GITHUB-300	GitHub as an active part of the harness: the full feature catalogue (covers GITHUB-500)	user	partial (P3.1)
GITHUB-COMMUNITY	People can collaborate, help and interact	user	partial (P5.4)
GITHUB-ONLY	GitHub is the only host	user	partial (P2.1)
WS-RECORDS	Older workspace records are read-only, upcast in memory, and never written	coordinator	done

Brand and public messaging

Id	Decision	By	State
MKT-ROADMAP	A roadmap that is easy to follow and generated from the records	user	partial (MKT)
MKT	One honest source for everything the project says about itself	user	pending (MKT)