Bridlewise
/
Decisions
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).
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
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
INSTRUMENT-LOCK The host has one instrument lock
coordinator
done, 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
pending (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
partial (NOLOAD (engine suite next; the web suite’s per-test overrides next))
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
partial (AMBIENT-ALLOWANCE-REMOVE)
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
partial (AMBIENT-ALLOWANCE-REMOVE)
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)
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-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)