Software Build Assurance Kit v1.0.5

Release notes - v1.0.5

This is the current release of the Software Build Assurance Kit - the cold-start patch on the GA release. The 1.0 bar is an integrity bar, not a feature bar: five decision-record properties, each demonstrated absent-of-defect by execution on verifier-built fixtures, in the authoritative CI environment. The evidence trail for every claim below is public in this repository's checks and in example-receipt.html.

Read this page before you adopt the kit for anything you care about. It says what works, what does not, and what evidence backs each claim. The release history in the same shape is in CHANGELOG.md.

What v1.0.5 changes

No interface changes to the build loop. This patch closes what the first fresh bootstrap on the previous release and a real multi-milestone build surfaced - the install story, the opening ceremony, the cost of starting a session, and the handoff between the two terminals:

• One file installs the kit. Download sbak-install.cjs from the release page into the directory the kit should live in, start claude, type sbak-install. The script carries its own instructions and is attested with the release beside the ZIP. It pins the release it installs, verifies the ZIP's checksum and - where gh is available - its attestation, discloses what it will write, asks one question at a time (answered by the word that names the action), and writes nothing before your word. A real CLAUDE.md is combined through one import line, never replaced without the word. The same command upgrades an installed kit: sbak/ and the live kit files refresh, and files you modified are kept and named; the bootstrap-filled files (the pre-commit hook and verify-local) stay at the installed version and are named - migrate them by hand until kit-update --migrate lands. The signed ZIP stays available as the manual path.
• One question opens the bootstrap. Full or Custom. Full (the default) asks nothing more: the operating mode is inferred from what you say you are building, the risk posture derives from the spec by script, and the whole calibration shows as one acceptance line you press enter on. Custom runs the short interview. The boot-time ceremony a read-only audit of every ritual could not tie to a named failure is gone; what stayed had earned its place.
• Orientation loads lazily. The session-start stamp stays eager - a stampless session fails loud from the hook - while the reading list is a manifest read at its own moment (stage open, verify, closeout) with each read recorded; the red-approval refuses a stage whose required reads were never recorded. Sessions start at a fraction of the context cost.
• A channel between the two terminals. The orchestrator and the builder exchange stage packets - stage open, the plan, the red-stop, the stage-end, the verdicts - over a file-based, append-only log, picked up automatically in both directions. Approvals are never automated: the RED release and the commit approval stay the human's keystrokes.
• Verification lanes in the generated project's floor. fast, stage and release lanes over one registry, an always class that rides every lane, settled marking for closed milestones with an affected-files override, and a union pin proving no test falls between lanes; the test estate is reviewed at closeout.
• The accumulated field findings. The settings deny list names the real .env variants and carries no catch-all, so .env.example - the mandated committed artifact - passes; the retrospective ends in a machine-checked handoff note; the closeout packet leads with deltas-from-plan and the open findings and is validated before it surfaces, and the release-state row is required at closeout; the gate manifest is validated.

What GA means here

The GA decision record required, and independent verification confirmed by execution:

1. Adoption never mutates outside the project root - symlink escapes (external, internal, dangling) are refused at every install site, targets byte-untouched, loudly and non-zero.
2. Adoption never reports success with controls dormant - hook wiredness is parsed, not pattern-matched; a fresh session proves the read-first stamp before success is claimed.
3. The release verification lane has no silent or required skip - every task appears in the run's own machine-readable summary with a verdict; a required skip is a failure, never a pass.
4. POSIX hook liveness is proven, not assumed - rendered hooks execute on Linux CI with the executable bit asserted; a Windows-local green is disclosed as non-authoritative at the point of use.
5. A failed settings merge cannot destroy user settings - byte-exact archive, atomic replace, auto-restore proven on a planted mid-write failure; unparseable settings are never replaced.

Each was verified twice: by the framework's own gates, and by an independent fresh-context verifier session that built its own fixtures and reproduced the release lane in a pristine clone.

Capabilities

• A one-question bootstrap. Full or Custom. Full infers the operating mode from your description, derives the risk posture from the spec, and shows the calibration as one acceptance line; Custom asks three short questions plus a confirmation turn. Everything else is derived by a script from a single authority file and surfaced with its one-line why. No interview sprawl.
• One-file install and upgrade. sbak-install.cjs, attested beside the ZIP, drives the whole install from inside claude - checksum and attestation verified, blast radius disclosed, one question at a time, nothing written before your word - and upgrades an installed kit the same way, keeping what you modified and naming the bootstrap-filled files it leaves at the installed version.
• A channel between the two terminals. Stage packets and verdicts travel between the orchestrator and the builder over an append-only log with automatic pickup; approvals remain the human's keystrokes.
• Four operating modes. greenfield builds something new. bug_fix reproduces a defect, fixes it minimally, and verifies once. audit reviews an existing codebase and produces findings rather than code. research_publish synthesizes sources into a paper plus an illustrative app, with every claim bound to a logged source.
• A red-first stage loop with teeth. A hook blocks edits to implementation files while a stage is open and the failing test has not yet been approved by a human. Tests come before code because the tooling will not permit the reverse.
• Blind verification with a calibration gate. Each milestone ends with a verifier session whose reading list structurally omits the builder's notes. Before its findings are counted, it must catch every defect in a seeded set. A verifier that misses seeded defects is not trusted with real ones.
• A human-drive floor. A Full-tier spec carries an in-real-life / human-in-the-loop plan - drive moments, what the human verifies by hand, where each answer gets typed - checked mechanically, and the milestone closeout consumes it: human-typed drive answers are required beside the closeout stamp before the closeout counts. An agent's recorded drive alone no longer satisfies the close.
• Sessions that say what they are. The session-start stamp identifies the session's role in plain words plus the checkout topology; the mode-setting script prints the launch order that prevents the shared-role-file race; a topology assist prints the worktree-split steps when the split is available and not yet taken.
• Verification lanes over one registry. verify-local --lane fast|stage|release - three filters over a single task registry, with release derived as the complete registry so omission is structurally impossible. Every run emits a deterministic JSON summary (verdicts, named skip reasons, durations in stated milliseconds, a registry hash). The bare invocation is the complete floor; fast and stage are developer feedback and are never release evidence.
• An enforcement layer that is itself tested. Validators and hooks guard the stage protocol, the retrospective stamp, test honesty, risk declarations, destructive operations, release readiness, entry-doc drift, spec-example coverage, and more - and an enumeration check in CI proves each shipped validator is catalogued everywhere that lists them. A regression suite proves each check still fires; sbak/scripts/bake-inheritance.cjs ships as the effectiveness proof a reader can run.
• Evidence you can read. Sessions leave append-only event ledgers. A collector turns those plus committed history into a deterministic report bound to real commits, showing findings, fixes, and rework - with unknown values reported as unknown rather than as zero.
• Reproducible, provenance-carrying artifacts. The starter archive is built from a signed tag, never from a working tree. The same tag always produces the same hash. This release's artifacts are sbak-v1.0.5-starter.zip and, beside it, sbak-install.cjs - both attested.
• Runs on a supported runtime. CI and the generated workflows pin Node 24 (Active LTS), and a floor check derives the minimum Node the kit's own prescribed test form requires from the prescription itself - the pins and the prescription cannot silently diverge again.

Limitations

The honest list. Every item here is a reason not to trust the kit further than it has earned:

• On a small solo build the weight is not worth it, and the trial that showed this was our own. The same small markdown-to-HTML CLI was built twice - once under this framework, once under a lightweight control loop. The framework arm cost ≈13.6× the dollars and ≈10.9× the API time. Its ratified adjudication FAILED two of its six thresholds for that project class: adaptability and economic justification. Four passed, including one evidence-bound prevented defect class (com...

Software Build Assurance Kit v1.0.4

Field-test patch on the GA release — no interface changes. Closes what the first real end-to-end adoption surfaced: the human-drive floor (a Full spec must carry its human-in-the-loop plan, and closeout consumes it — typed human answers before the stamp counts), session identity and topology mechanics at the two transition moments, regex-construction hardening across the validator layer with all three public code-scanning findings adjudicated, pinned line endings with a Windows CI job reproducing the default-clone environment (that job caught and closed an 8.3 short-name adopt refusal in this very patch), and the documentation fixes a real adoption run surfaced. Full detail: RELEASE-NOTES.md and CHANGELOG.md. Starter ZIP sha256: 630b49e499d2836ec6f91705a6925331fc0bd37a708645725805d1619afbae09

Software Build Assurance Kit v1.0.3

Hardening patch on the GA release — no new features, no interface changes. Docs brought to consistency against final behavior; release chain and enforcement layer hardened: derived version literals with a staleness sweep that fails the build, assembled-tree require resolution before a tag is cut, a zero-recorded-executions detector, fail-closed adopt at every destination, the red-gate self-approval carve, and a realistic verifier calibration exam (11/11 filename leaks before, 0/11 after). Full detail: RELEASE-NOTES.md and CHANGELOG.md in the repository. Starter ZIP sha256: 5de468cc0fee9d20e88f854e269bd508e26abc7345e79ba28a7f36759b328544

Software Build Assurance Kit v1.0.2 — GA

The GA release of the Software Build Assurance Kit.

The 1.0 bar is an integrity bar, not a feature bar: five decision-record properties, each demonstrated absent-of-defect by execution — three-site symlink confinement, parsed-wiredness adoption, a zero-silent-skip release verification lane, POSIX hook liveness in authoritative CI, and byte-safe settings merge with proven restore. Independently verified twice; CI green on the pinned Node 24.

Install: download sbak-v1.0.2-starter.zip, verify (sha256sum -c against the sidecar, or gh attestation verify), unzip into your project, run the adopt step — full steps in sbak/QUICKSTART.md §1.

sha256: bc8745186abcc95417315dd4e421142b8b761e3ffd9003df58133286fcda6826

(v1.0.1 was published without its attestation and stands superseded; v1.0.0 was tagged but never published — its manifest lacked one file, caught by this repository's own CI. Read RELEASE-NOTES.md for what this kit claims, what it does not, and the honest costs — including the trial where our own framework lost on price for small solo builds.)

Software Build Assurance Kit v1.0.1 — GA

The GA release of the Software Build Assurance Kit.

The 1.0 bar is an integrity bar, not a feature bar: five decision-record properties, each demonstrated absent-of-defect by execution — three-site symlink confinement, parsed-wiredness adoption, a zero-silent-skip release verification lane, POSIX hook liveness in authoritative CI, and byte-safe settings merge with proven restore. Independently verified twice; CI green on the pinned Node 24.

Install: download sbak-v1.0.1-starter.zip, verify (sha256sum -c against the sidecar, or gh attestation verify), unzip into your project, run the adopt step — full steps in sbak/QUICKSTART.md §1.

sha256: 2090c8084c90064b37fa7760e78ce68362ced3ab59cbd81310a32b7e08a70e34

(v1.0.0 was tagged but never published — its manifest lacked one file, caught by this repository's own CI. Read RELEASE-NOTES.md for what this kit claims, what it does not, and the honest costs — including the trial where our own framework lost on price for small solo builds.)

v0.1.0

Release notes — v0.1.0

This is an experimental release. It is the first public version of the Software Build Assurance Kit. Interfaces, file layouts, and command names will break between 0.x releases without a deprecation period. Nothing here is stable yet, and nothing here should be assumed safe because it is published.

Read this page before you adopt the kit for anything you care about. It says what works, what does not, and what evidence backs each claim.

Capabilities

What the kit does today, on any project you copy it into:

• A calibrated bootstrap. A short interview sets a tier (Lite, Standard, Full), an experience level, an approval cadence, a deliverable type, and where tests run. The kit then writes a scaffold sized to that answer — roughly 36, 68, or 69 files. Re-tier later by editing one file and logging why.
• Four operating modes. greenfield builds something new. bug_fix reproduces a defect, fixes it minimally, and verifies once. audit reviews an existing codebase and produces findings rather than code. research_publish synthesizes sources into a paper plus an illustrative app, with every claim bound to a logged source.
• A red-first stage loop with teeth. A hook blocks edits to implementation files while a stage is open and the failing test has not yet been approved by a human. Tests come before code because the tooling will not permit the reverse.
• Blind verification with a calibration gate. Each milestone ends with a verifier session whose reading list structurally omits the builder's notes. Before its findings are counted, it must catch every defect in a seeded set. A verifier that misses seeded defects is not trusted with real ones.
• An enforcement layer that is itself tested. 16 validators and 4 hooks, plus committed git hooks, guard the stage protocol, the retrospective stamp, test honesty, risk declarations, destructive operations, release readiness, and more. A regression suite proves each check still fires; remove a check's teeth and a test goes red.
• Evidence you can read. Sessions leave append-only event ledgers. A collector turns those plus committed history into a deterministic report bound to real commits, showing findings, fixes, and rework — with unknown values reported as unknown rather than as zero.
• Reproducible, provenance-carrying artifacts. The starter archive is built from a signed tag via git archive, never from a working tree. The same tag always produces the same hash.

Limitations

The honest list. Every item here is a reason not to trust the kit further than it has earned:

• No worked example ships in this release. There is no end-to-end tutorial project you can read start to finish. The kit's own build receipt is included as example-receipt.html, and it is real — derived from this repository's actual commits, findings, and rework — but it is evidence of the process running, not a guided walkthrough. A worked example is planned for a later release.
• No human security audit has been performed. None is claimed. The release ladder stops at packaged-release-ready, with build provenance at SLSA Level 2 and nothing beyond it. Absence of a claim is not a claim of absence.
• Experimental, and interfaces will break. Pin a tag. Do not track the default branch.
• The overhead is real and sometimes not worth it. For work that fits in an afternoon, or throwaway code, or a project no one will ever need to reconstruct, this kit costs more than it returns. WHY-THIS-KIT.md names the cases where you should not use it, and means them.
• The static gate floors cover four language families — JS/TS/JSX-TSX, Python, Go, and Rust. Anything else gets a visible skip line plus verifier-stage coverage. Disclosed, never silent, but a skip is a skip.
• The permission fence is a fence, not a sandbox. Its deny rules have known bypasses. Keep secrets off disk.
• Token cost is higher than a plain instruction file. The kit caps per-session reading lists to keep this bounded, but a framework of this size costs more to run than a concise CLAUDE.md.
• The human stamp is load-bearing. If stages are approved without reading the diffs, every control in the kit degrades to ceremony.
• No controlled study shows this approach beats a concise instruction file plus tests plus code review. The design is a reasoned bet on the evidence, not a demonstrated win.
• Pull requests are not accepted at v0.x. Development is private and this is a snapshot. Issues are read; no response time is promised.

Evidence

What backs the claims above, and how you can check it yourself:

• Continuous integration runs the kit's enforcement layer against the kit. On every push and pull request: the stage-prompt schema check over every phase document; an enumeration check proving each shipped validator is catalogued everywhere that lists them; the seeded-defect calibration set, checked in both directions so no fixture leaks its own answer; a self-description check proving the numbers in the documentation match the code they describe; the golden-scaffold check, so a template edit cannot silently change what a bootstrapped project receives; and a bake harness that renders a real project, plants a violation, and requires the inherited validator to reject it. Presence is never taken for effectiveness.
• The build receipt is real. example-receipt.html is derived by the collectors from this repository's own commits, findings, and rework. It is not a staged demonstration and it does not hide its gaps: intervals that are unknown are printed as unknown.
• Artifacts are verifiable. software-build-assurance-kit-v0.1.0-starter.zip ships with a .sha256. It is built from the signed tag, not a working tree, and carries SLSA Level 2 build provenance. Building the same tag twice produces the same hash.
• The claims in the documentation are machine-checked. Counts, gate ranges, the protocol version, and the covered-language set are derived from the code and validated in CI. A number that drifts fails the build rather than quietly misleading a reader.
• The research behind the design, including the evidence against it, is collected in WHY-THIS-KIT.md with citations pointing in both directions.

Getting started

README.md for the overview, QUICKSTART.md for the ten-minute path, HOW-IT-WORKS.html for a visual tour, WHY-THIS-KIT.md if you are still deciding.

Run the kit from inside your own project directory — not in a clone of this repository. It writes into the directory it is run from.

License

MIT. Copyright (c) 2026 Kurt Knipe.