BuilderOS 3.1.0

After 3.0.0: what existing projects meet when the rules change, two sessions on one initiative, work that waits on a round, how a model-driven product behaves, the craft of what the person sees, a backend designed, secured and measured before it ships, flows drawn as diagrams the person edits, a video of every feature working, and the value, the stake and the go-to-market of a bet. Analysis and decisions (1B, 3A, 4A) in the project thread "Cosa migliorare ancora" (cosa-migliorare-ancora-2026-10-21.md); the backend and the interface bar in "Design eccellente e backend solido" (round 1, recommended options); diagrams and demo videos in "Diagrammi dei flussi e video e2e" (1A with an editable page and Pele, 2A with the video outside the codebase, 3A, 4A). What a person opens, clicks and receives (production from the first slice, a build tried before it is accepted, the project page, the messages a product sends, languages, help) in "Trovare cosa manca davvero a BuilderOS" (cosa-manca-davvero-2026-10-24.md, 1A 2A 3A 4A). The value of a bet, the stake and go-to-market in "Decidere cosa costruire con probabilità e GTM" (probabilita-gtm-scommesse-2026-10-24.md, 1A 2A 3A 4A).

Changed: gates check facts, not form

Measured on a hollow project (tests/fixtures/hollow): every artifact a gate asks for exists and nothing it describes does. Sixteen conditions of gates 4 and 5 passed on it; tests/scripts/hollow.test.mjs now requires each to fail and say why.

• Files hold what they claim. Design versions, reference screens, captures and step screenshots must be real images (PNG, JPEG, GIF, WebP read by their headers), prototypes and previews HTML with visible text, recordings real video (4.9, 4.10, 4.21, 5.9, 5.15). One capture cannot stand for several states, and captures must match a reviewed width.
• Runs run something. A captured command that only prints or exits (echo, true, printf, …) fails wherever a run is evidence; the demo's run must run its test; a performance row's number must appear in its run's output (5.14); the production check must call the production host (5.16). Instrumentation needs a data tag or a captured run, never a code tag (5.3).
• The guardrail exists. 5.8 opens the file the guardrail names and finds a Verify command in it; 5.10 finds each quality check's tool there.
• Reviews say what was looked at. A craft critique or security review where every row is a bare "none found" fails (5.12, 5.13).
• Users, money and tests are read, not mentioned. A plan to meet users is not a session (4.13); "said they would pay" is an opinion, an act is a pre-order, a payment, a signature (4.14); 4.22 reads the channel test and any test-first card against their stop lines, on every track.
• Person fields quote the person. The message hook appends each message to .builderos/person-log.jsonl, which the guard keeps out of hand edits. Chosen by, Accepted, Tried by, Rules decided by, Authorized by, --accepted-by, and the reasons of a kill, a jump or an override quote it; a quote the person never wrote fails. Without the log the field passes, marked unverified.
• Tests decide. record N --kill "reason" at phases 0 to 6; an override waives conditions by name (--waive 4.22,5.8), never several by accident; the bet's appetite shows in the briefing and, once spent, in every message line.
• A change costs what it touches. Six things always (scope with **Touches:**, criteria, impact on what it touches, tests against the baseline, the scope check, rollback); interface, copy, data, personal data, permissions, money, messages, contracts and stack each call in their own conditions. A slice editing a screen or a schema it did not declare fails the scope check. A label rename passes gates 4 and 5 on one page each.
• Every move has its command. bos.mjs init, resume, reframe, jump. The project page names what the current phase waits on from people.
• Order. The real-user session follows the flows, on a clickable prototype design-direction builds; the go-to-market, the test and the appetite come before the person picks the bet; slice zero lives in the accepted plan; the demo is recorded after the person tried the build. Frame, discover, define and ship return the person's round instead of choosing in a subagent; the build reviewer runs steps 7 and 8 only.
• One place per fact. One Cheapest test template with its Result; the price in PRODUCT.md, drafted at initialization with the rest of ## Business; the channel in Go-to-market; one stage model, with Signal, Resonance and Orbit as its go-to-market names.
• Each gate file lists its attested conditions, the ones resting on a fact outside the repository that the script checks only by citation.

Added

• Gate records carry their version. record, cover and gate --json store bos_version and the conditions skipped as not applicable, so a later release can tell "not applicable then" from "not there yet". A test keeps VERSION in scripts/bos.mjs equal to package.json.

• Debt after a release. The briefing lists, per initiative, conditions now in force that a passed gate never checked and its artifact does not meet yet; the phase stays passed (gate-checks, Debt After a Release). An initiative whose gates passed under 2.1 now sees what 2.2 to 3.0 added.

• bos.mjs doctor: Node, the hooks next to the script, the project copy, PRODUCT.md, TECH.md, AGENTS.md and its BuilderOS block, each initiative's state and claim, and the debt per phase with its detail. /builder-os:bos-status --doctor relays it.

• One owner per initiative. bos.mjs claim --by "who" (--release, --take --reason), shown in the briefing and in the per-message line; a second claim is refused. Events claimed, claim_released, claim_taken; a claim older than 14 days is flagged.

• Rounds are recorded, and the work goes on while one waits. bos.mjs round --asked N and --answered "1B, 2A" --by "who" (events round_asked, round_answered with the hours waited; pace shows the median wait). While a round waits, the agent drafts ahead on the recommended options in blocks marked **Provisional:**, kept apart from **Chosen by:** and from decisions/; the answer keeps or deletes each block (pressure-testing, Working Ahead). Gate E.2, on every gate, fails while a marker is left.

• agent-design and gate 4.16, when the spec declares model output: autonomy per action (does, proposes, asks, never, with never enforced by withholding the tool), every asks as a tested acceptance criterion, the hand-off, injection surfaces each with a mitigation and a must-pass eval case, degradation for slow, down and wrong, and a latency budget per turn. Gate 6.10 adds **Agent traces:** to production readiness and, after PMF, **Model degradation:** to TECH.md → Operations. logs.query covers model traces. Eval case agent-autonomy.

• Design craft. design-direction studies three to five real reference screens before drawing, and each version names the generic default it avoids; versions may embed a real typeface instead of system fonts. Gate 4.9 counts the references and checks the Avoids column. The build reviews all six states at two widths (5.9; empty and error at one width on the change track) and gets a fresh-context craft critique of hierarchy, spacing rhythm, typography, copy against the voice, focus states and motion (new gate 5.12).

• The first day (product track, gate 4.17): a ### First day flow from the first visit to the first useful outcome, and **Activation:** in the spec citing its acceptance criterion and the tracking-plan event that measures it.

• system-design and gates 4.18 and 4.19: the backend is designed in phase 4, after the domain and the stack. ## Architecture holds the components with what each owns, the contracts (errors, paging), every external call with a timeout, a retry rule, its idempotency and what the user sees when it fails, six scale defaults that cost little now and a rewrite later (owner key on every row, paginated lists, indexed queries, idempotent writes, slow work off the request, reversible migrations) and a capacity at ten times the stage's expected load. ## Threat model names the trust boundaries and always covers another user's or customer's data, untrusted input, abuse and secrets, each mitigation tested by an acceptance criterion. Gate 4.15 states that the scale defaults are not scale work.

• Security and speed checked on what was built. A fresh-context security review of the diff against the threat model (new gate 5.13: access control, input handling, secrets and configuration, abuse limits, data exposure) and the performance budget measured on the built product, with a page-load row for an interface (new gate 5.14). Gate 5.10 adds static analysis, a token check with an interface, and visual regression once a look has shipped. After PMF, gate 6.10 asks for **Load tested:** in TECH.md → Operations.

• Interface details (design-direction/references/interface-details.md): tokens enforced in the code, every state of every control, feedback within 100 ms, no layout shift, forms, keyboard, content, state in the URL, motion, themes and Core Web Vitals. The build applies it; the craft critique (5.12) adds interaction states and a row comparing each capture with the reference screens.

• Flows drawn, and editable by the person (gate 4.20). Each flow in DESIGN.md carries a Mermaid flowchart under its steps table (entries, decisions with labeled exits, success and abandonment), and each lifecycle in the domain model a stateDiagram-v2 holding every state its transitions table names. bos.mjs flows writes design/flows.html, at no model cost: each flowchart on a hand-drawn canvas (Excalidraw, MIT, laid out by its Mermaid importer) where the person drags, adds, joins and renames boxes, turned back into Mermaid ...

BuilderOS 3.0.0

A major version because existing work changes under it (#16, #17, #18): six analysis skills and six agents are replaced by product-analysis, and frames, discoveries, definitions, specs, build plans and releases written before now fail new gates until they carry the new sections (see each Upgrading note). What it adds: hooks for the rules that must always hold, gates on the quality of what is built, the product loop from stage to payment, decisions recorded as the person's, wayfinding, retro, to-spec, to-tickets, agents-md, and every skill rewritten to one writing standard kept by a test.

A deep pass against what a tier-1 product team would do, and against the Claude Code plugin guidance. Analysis and decisions (Q1 to Q7) in the project thread.

Added

• Hooks for rules that must hold every time. PreToolUse denies a hand-written state.json (bos.mjs guard); UserPromptSubmit adds one line per message with the phase and what to check the request against (bos.mjs context).
• The script travels with the project. bos.mjs vendor copies it to .builderos/bin/bos.mjs; init runs it and writes the Session Start block into both AGENTS.md and CLAUDE.md. The briefing flags a stale copy.
• Evidence from outside the session. bos.mjs evidence add --class interview|doc|data --id --where [--shared] [--from file] saves notes, tickets, exports or excerpts as evidence files the tags resolve to. Raw material is required, files are never overwritten, one participant per interview file. Starting with no evidence is described in references/lifecycle-setup.md.
• Quality of what is built. Gate 4.12 quality bar (permissions, personal data, performance as criteria or a reason), 4.13 a real-user session before the build on the product track, 5.9 interface review of the built states against the chosen direction, 5.10 automatic quality checks in the guardrail (accessibility, end-to-end, dependency audit, secret scan), 6.10 production readiness (errors seen before users report them, a restore tested), 6.11 first real use on the product track. New capability ui.capture.
• Eval suite in evals/ for claude plugin eval: routing, briefing, evidence, gates, with and without the plugin. CI runs npm test on GitHub Actions.

Changed

• Session context from 8,440 to about 2,100 characters on a project, briefing first; two lines outside a project.
• Code before an accepted build plan is a stop, not a flag, even when the user says to skip: name what the gate needs and offer to finish it, a change, or a recorded override. Found by the first eval run, where the plugin wrote code at phase 2.
• product-analysis replaces saas-metrics-reference, growth-frameworks, financial-models, okr-frameworks, strategy-frameworks and competitive-intel; their procedures are its references. product-diagnostician runs any of its areas; the agents growth-architect, finance-analyst, okr-architect, north-star-analyst, competitive-analyst and product-strategist are removed.
• Skill descriptions say what the skill does and when to use it. With the new outside-project session line, skills loaded on a standalone PRD and a retention question went from 0 of 4 eval runs to 4 of 4.

Upgrading. Specs fail 4.12 until ## Quality bar is written (and 4.13 on the product track until ## Real users); build plans fail 5.9 until ## Interface review, and 5.10 until TECH.md has **Quality checks:**; releases fail 6.10 until ## Production readiness (and 6.11 on the product track until ## First real use). Run bos.mjs vendor once in each existing project.

The person decides, and four skills from Matt Pocock (2026-10-21)

Where BuilderOS still let the agent decide, it now asks; and the parts of Pocock's skills it lacked are in. Analysis in the project thread "Skill scritte alla Pocock" (skill-alla-pocock-2026-10-21.md), decisions 1A 2A 3A 4A.

• Decisions belong to a person. The agent analyses and recommends in a round; the person chooses, recorded as **Chosen by:** and checked by the script: the assumption phase 1 tests (gate 0.5), what a discovery verdict means for the work (1.6), the opportunity and its target (2.8), the rollout (6.13), keep, iterate or kill (7.7), next to the bet (3.6) and the look (4.9) that already were. Scope boundaries in the spec and the slicing of the build plan are round questions too.
• pressure-testing is relentless. It keeps a design tree and stops when the frontier is empty, not after one round; each question is worded so "yes" accepts the recommendation; facts are looked up in parallel while the rest of the round is asked.
• wayfinding (from Pocock's wayfinder): work too big for one session becomes a map in .builderos/maps/{slug}/ with decision tickets (research, prototype, grilling, task), the fog of war and out of scope, one ticket per session. bos.mjs map prints the frontier; the briefing shows the next ticket of every open map.
• retro, to-spec, to-tickets, called by name on Claude Code and Codex (disable-model-invocation, agents/openai.yaml), each over one method: retro holds the environment retrospective that phases 5 and 7 now run; to-spec runs the new Synthesis Procedure of spec-writing (no interview, one question on the test seams, gaps named); to-tickets runs delivery-discipline/references/tickets.md (vertical slices, expand–contract for wide refactors, a quiz on the breakdown, one ticket per file or per issue). The spec template gains ## User stories and ## Test seams; the build plan gains **Tickets:** and ## Retro.
• New capabilities tickets.write and sessions.read.
• Every skill rewritten to one writing standard (decision 1A), after Pocock's writing-for-agents and Anthropic's skill guidance, and a test that keeps it (tests/scripts/skill-writing.test.mjs): descriptions at most 250 characters with what the skill does and when to use it; one Mode line pointing at references/operating-modes.md instead of five copied variants (delegation now lives there, once); every skill that drives work has ## Procedure with numbered steps that each end on Done when, and an output contract with its completion marker; guidance written as the behavior wanted, in Watch for tables (Do / Instead of) that replace the Common Mistakes tables; every relative link resolves. Across the 28 skills: prohibitions 148 → 31, description text 8,334 → 6,575 characters, completion criteria 14 → 193, words 30,718 → 28,924. spec-writing moves its synthesis procedure to references/synthesis.md and the real-user session script to its methods; delivery-discipline and spec-writing collapse their standalone and lifecycle procedures into one, so the step numbers named by the agents changed (build reviewer: steps 7 to 10).
• The coding agent stays on the code (round 2, decisions 5A 6A 7A 8A). TECH.md → ## Map says where the entry points, modules, tests and generated files are; AGENTS.md stays a short index of pointers, commands and must-hold rules. New skill agents-md creates or prunes AGENTS.md and CLAUDE.md on any repository, showing the diff before touching the person's lines; init runs it, the build updates the map, ship adds pointers to promoted files. Gate 5.11: a map exists and every path in it, AGENTS.md and CLAUDE.md exists. The briefing flags a dead pointer, a DOMAIN.md older than the last schema or migration change, and an AGENTS.md over 150 lines.

Upgrading. Frames, discoveries, definitions, releases and outcomes fail their gate until the decision carries **Chosen by:** from the person's answer. Build plans fail 5.11 until TECH.md has ## Map; run agents-md once in each existing project.

From one bet to a product that earns (2026-10-21)

The lifecycle shipped one bet well and said nothing between bets or around the product: no stage, no link from initiatives to a North Star, no channel, price or payment, no operations beyond the first incident. Analysis in the project thread "Da zero a milioni" (da-zero-a-milioni-2026-10-21.md), decisions 1A 2A 3A 4A.

• The product loop. PRODUCT.md → ## Business replaces ## Success: stage exit thresholds, North Star, revenue model, growth engine and a metric tree of three to six levers. A product review (skills/builder-os/references/product-review.md, /builder-os:bos-review, checked by bos.mjs review, conditions R.1 to R.5) reads every lever, judges the stage, and proposes one to three initiatives for a person to pick; it is written to .builderos/reviews/. The briefing flags it weekly before PMF and monthly after. Gate 2.7: each initiative names the lever it moves.
• The stage changes the rules. Before PMF scale work is rejected (2.5, new 3.8 and 4.15, model-judged), experiments are judged qualitatively against thresholds written first, concierge and Wizard of Oz are the preferred tests. After PMF, operations carry an SLO, incident response and a cost per active user.
• Distribution and money in the bet. Gate 3.7 (product track): ## Business case with the first 100 users, cost per user, and for a product for sale the price and the willingness-to-pay test. Gate 4.14: a tagged willingness-to-pay result and a payments row in the stack (payments and tax join the layer catalogue, with the Italian SdI and EU OSS case). Gate 6.12: a first real payment before phase 7. Products "not for sale" skip the money lines. Subscription states join the domain method.
• Operations by stage. Gate 6.10 now also reads TECH.md → ## Operations: Privacy always, AI disclosure when a model speaks (AI Act Article 50), SLO, incident response and cost per active user after PMF. Product facts written once, not per release.

Upgrading. Gate 2.7 warns until a first product review writes the metric tree. Product-track bets fail 3.7 until PRODUCT.md declares a revenue model and the be...

BuilderOS 2.3.0

Work on a product that already exists (#14): a new change track, the request's own evidence on the feature track, the impact on what exists, project-level DOMAIN.md and design system, cleanup after a decision, and gates that cope with a suite already red. New gates M.1 to M.4, C.5, C.6, 4.11, 6.9 and 7.6; new command bos.mjs upgrade. No new phases, skills or slash commands.

Work on a product that already exists (2026-10-20)

BuilderOS was shaped around a new product walking from phase 0 to 7 once. On a live product the work is different: many small changes, in parallel, in code with history, red tests, CI owned by others and users who already rely on the old behavior. Analysis in the project thread; decisions 1A to 4A.

Added

• change track. A modification whose solution is already decided (bug, debt, compliance, contract, exactly specified request, removal). 00-request.md carries the request, its evidence, its population and the mandate; the mandate check (gate M: M.1 source, M.2 kind, M.3 why no bet, M.4 judged) covers phases 0 to 3 and the work starts at the spec in lite mode. Gate 4.4 is skipped, the look can be inherited with a reason, phase 5 is unchanged, and phase 6 closes the initiative unless the release sets an outcome review. A failed mandate check moves the work to feature. bos.mjs new --track change, cover --m4.
• bos.mjs upgrade --to feature|product --reason: the ratchet as a command, back to phase 0 with the artifacts kept.
• The request's own evidence on the feature track. 00-request.md is required there too; C.5 checks its evidence and population (only the requester's words is a warning), C.6 warns on problem evidence older than a year, and gate 2.1 accepts tags from 00-request.md and the initiative's own evidence/. Init on a live product harvests the evidence that already exists (tickets, analytics, call notes) before the coverage check judges it.
• Gate 4.11, impact on what exists. The spec states, for existing data, contracts, tracking events, permissions and current users, what changes and how it is handled. Never relaxed in lite.
• DOMAIN.md and TECH.md → Design system, and gate 6.9. What an initiative modeled and chose leaves its folder at ship: entities and rules into DOMAIN.md, kit and token location into TECH.md. domain-model and design-direction start from them and ask only the delta.
• Gate 7.6, cleanup. Every decision schedules what to remove: the flag and old path after KEEP, the shipped code after KILL.
• Release notes say what changes for existing users, not only what they can now do.
• Pre-existing failures. A suite already red before the change: gate 5.2 compares the final run with the captured baseline (listed failures present in the baseline log, no more failures than before, a separate green run of the mapped tests) instead of demanding exit 0. TECH.md gains Known failing and Test (fast).
• Where the work lives. Lifecycle files before code on the default branch, from the build with the code on its branch, an abandoned branch recorded as a decision; the briefing names initiatives that exist only on another branch. Multi-repository and monorepo limits stated.

Changed

• C.3 no longer accepts a code tag as evidence of a problem.
• Gate 5.8 accepts declined by {person} ({why}), {date} as a visible warning when the CI belongs to someone else.

Upgrading. Specs written before this fail 4.11 until ## Impact on what exists is added; releases fail 6.9 until the domain and look are promoted; outcomes fail 7.6 until **Cleanup:** is written. Feature initiatives created before this keep their covered phases; new ones need 00-request.md.

Verification. 89 Node tests pass. Behavioral scenarios on Claude Code 2.1.305: the two new cases (live-product-first-feature, change-with-red-suite) and both feature-track cases pass; the first runs found three defects, fixed (see tests/scenarios/README.md). The other five cases were not rerun.

BuilderOS 2.2.0

Everything merged since 2.1.1, in three blocks: the SDLC alignment (#9), BuilderOS as a copilot (#10, #11), and the design, stack and guardrail rework (#12, #13). Four new skills (stack-decisions, design-direction, domain-model, bug-diagnosis), two new capabilities (ui.render, logs.query), new gates 3.5, 3.6, 4.7 to 4.10, 5.6 to 5.8, 6.8 and 7.5. No new phases or commands.

Upgrading. Specs and build plans written with 2.1.1 fail gates 4.7 to 4.10 and 5.6 to 5.8 until the new sections are added. bos.mjs new now refuses to run without --track.

Verification. 74 Node tests pass. All 9 behavioral scenarios passed on Claude Code on 2026-10-05, before #12 and #13; they were not rerun after them.

Design, stack and guardrails (2026-10-20)

The design and stack choices stop happening by accident. Before this, no phase decided the stack (TECH.md stayed "no code yet" until the first build slice picked one), the visual layer was declared out of scope when no design tool was connected, and phase 3 stopped at the three options the gate counted and could pick the bet itself. Now each of these is a choice the user makes, in rounds, knowing what is chosen, why, what it costs and what the alternatives were.

Added

• stack-decisions skill. Layers the work touches are inherited, decided or not needed; every open layer becomes a decision card (plain-language gloss, cost tagged or flagged unverified, lock-in, what would make us switch, the boring default always among the options) asked in rounds, with drivers traced to PRODUCT.md and an ADR for hard-to-reverse choices. Feature track inherits the stack and asks only what the feature adds or strains.

• design-direction skill. At least three visual directions on a new product, two layout versions inside an existing design system (or in lite mode), differing in structure (layout, hierarchy, primary affordance, density), never only in colour. On a running product they mount inside the real page behind a ?variant= switch on a throwaway branch; otherwise each is a self-contained HTML file under the initiative's design/ folder. Revisions are new numbered files; after three rounds without a choice it proposes fixing the strongest. The design kit is chosen after the interface layer; tokens and composition rules are extracted into DESIGN.md, and the HTML stays a reference, never code.

• domain-model skill. The entities the work touches, their states and transitions (who, under which condition, with which effect), invariants, awkward scenarios, and the business rules put to the user as round questions ("can a closed ticket be reopened?"). A clickable logic prototype (one HTML file, pure module, guided scenarios) when the rules are non-trivial, and a data sketch the stack decision reads. New terms go into PRODUCT.md → Language.

• Seams in the build plan. The modules the work creates or changes, their interfaces, what they hide and where tests sit, each with one plain line; the central module is designed two or three ways and the losers go under rejected alternatives. The plan opens with **In plain words:**, presented before acceptance. Tests are written at the seams the plan names.

• ui.render capability, with HTML files as its floor.

• Gates 3.5 and 3.6: at least eight raw ideas before convergence (five in lite), and **Chosen by:** naming the person who chose the bet.

• Gate 4.10: DESIGN.md → ## Domain model with entities, transitions naming who, invariants, data and the person who decided the rules, or "not applicable" with a reason.

• Gate 5.6 extended: the plain-words summary and the Seams table (interface, tests at, plain line per module).

• Gates 4.8 and 4.9: the spec's ## Stack lists every layer with its status, a person on every decided layer and existing ADRs, plus ## What we chose, a plain-language summary shown before acceptance; DESIGN.md → ## Visual direction with the versions, their files, who chose, the kit and the tokens, or "not applicable" with a reason.

• Briefing line when an open initiative is past phase 4 while TECH.md still has open or empty stack layers. Gates already passed are not re-checked.

• bug-diagnosis skill. A loop that goes red on this bug, captured before any change; the case made minimal; at most three hypotheses, each killed or confirmed by instrumentation one at a time; the cause fixed rather than the symptom; a regression test at the seam and a check for the whole class when it is mechanical; four plain lines for the owner. Phase 5 uses it for bugs, phase 6 for problems after exposure.

• Guardrails and gate 5.8. TECH.md gains **Guardrail:**: the CI job or pre-commit hook that runs Verify on every change. Slice zero adds one when there is none; gate 5.8 fails on "none". Mechanical review findings become checks in it; judgment calls go to Conventions for the reviewer.

• Environment retro in phase 7. What slowed or misled the agent this cycle, turned into a pointer, a check or a convention, recorded under Pipeline notes.

• logs.query capability, with the user's error text as its floor.

Changed

• Phase 3 diverges, then converges, and the person chooses. ideation-methods adds the ## Divergence list (with the user's own ideas) and makes selection a round; the solution-architect agent returns the round instead of picking.
• Phase 4 runs flows, rules, look, stack, kit, then the spec. /bos-shape runs domain-model, design-direction and stack-decisions in the main conversation, where the user can answer.
• Phase 5 builds on what was decided. A structural addition (framework, database, hosted service, paid API, runtime) stops the slice and returns to stack-decisions; utility libraries are listed in the review. An undecided layer or a departure from the tokens and kit is an Important review finding.
• Init no longer guesses a stack. Undecided layers are written open in TECH.md.

Verification

74 Node tests pass (67 existing, 6 new in tests/scripts/design-and-stack.test.mjs, 1 new for gate 5.8). The model-based behavioral scenarios were not rerun.

Copilot (2026-10-05)

BuilderOS as a copilot, shaped by the first real use (an internal team tool taken to phase 6): the questions offer choices instead of blanks, the start needs one sentence, the agent flags drift while you work, and the skills are half as long. No new phases, commands or capabilities.

Added

• Option rounds. Every pressure-testing question lists two to four options, each with its consequence, and recommends one with the reason. At most four questions per round, answered by code (1B, 2A). "Go with the recommendations" decides only when the user says it, records each decision as theirs and never fills a factual gap. Factual questions offer ways to close the gap, never guessed values. An answer that maps to no option and lifts a gate or scope limit is confirmed before it counts.
• Watch While Working in using-builder-os: before doing a product request, check it against decisions, PRODUCT.md non-goals, conditions set by earlier phases and the spec's out-of-scope (contradiction), update files the decision made wrong (stale truth), name unvalidated ground (shaky ground), and put measurement before more work on an unread result or an unstarted pilot. Two lines, never a block.
• Briefing attention: decisions past their Revisit when date or without one, [assumption:unvalidated] left in PRODUCT.md after phase 1, and history events outside the schema's list.
• Plain recap: every phase report opens with at most five lines for someone who did not follow the work.

Changed

• One-sentence start. /bos-init [idea] drafts PRODUCT.md from the sentence, announces name, track and mode as defaults the user can override, and opens the first round of the starting phase in the same turn. Procedure in references/lifecycle-setup.md.
• bos.mjs new requires --track. Without it the script created a product initiative, which a later classification could not undo.
• /bos --phase logs a phase_jump event.
• Editorial pass. SKILL.md files keep the procedure (42k → 21.6k words in total); methods, templates and examples moved unchanged into each skill's references/, read on demand. gate-checks is split into one file per gate, so a gate loads only its own conditions. The rule on retrieving facts before asking lives once, in references/operating-modes.md.

Fixed

• The financial-models output template was split across two files; a release-ops step pointed at the wrong step.

Verification

67 Node tests pass (3 new). All 9 behavioral scenarios pass on Claude Code; feature-track failed on the first run (the track defaulted to product) and passed 3 of 3 after the --track fix.

SDLC alignment (2026-10-04)

Aligns the delivery half of the lifecycle with Anthropic's AI-Native SDLC Playbook: the plan is reviewed before the code, a person accepts the work where it changes hands, the test loop cannot be weakened from inside, and production feeds the next cycle. No new phases, commands or capabilities; skills stay host-agnostic and every addition keeps a floor.

Added

• Acceptance, separate from the gate. bos.mjs record refuses to pass phases 0, 4 and 6 without --accepted-by "who", taken from the person's own words, and stores accepted_by and accepted_at with the gate and in history. A failed gate records no acceptance. gate-checks gains the Acceptance protocol; a standing instruction counts when it named the scope.
• Gate 4.7: the spec states its constraint conflicts (PRODUCT.md against TECH.md) with who decides each, or that none were found.
• Gates 5.6 and 5.7: the build plan (slices with files, risks, rejected alternatives, tests) is accepted before any code, and the final diff is judged against it.
• Gate 6.8: exposur...