Throughstone v1.4.0
A scaffold-update process release: it replaces the old "hand-copy upstream improvements" guidance with a conservative update model for bootstrapped projects, and tightens bootstrap and resume behavior before cutting the next tag.
Added
- Throughstone scaffold update guide (
UPDATING-THROUGHSTONE.md): an advisory-first process for comparing a project to a newer Throughstone release, classifying files by bucket, reporting risk/implications, and applying only reviewed scaffold/process changes. - Manifest + catalog model for future updater tooling: project state would live in
Code/{{PROJECT}}-docs/.throughstone/manifest.yml; release implications would live in an upstream update catalog; the updater itself stays stateless. - Three-way comparison rules (
base/local/upstream) and classifications: already-current, upstream-only, local-only, diverged, untracked, protected, and manifest-invalid, with baseline-unknown handling for projects that lack a trustworthy install-time manifest. - Mechanical risk signals for updater reports, including script changes, git/remote-touching commands, CI changes, placeholder handling, status resolver changes, incomplete update groups, and dirty affected repos.
Changed
METHOD.mdis now Method version 0.2 (beta) and points scaffold updates to the new guide instead of suggesting direct hand-copying.- The docs hub and template README now make clear that Throughstone improvements do not apply automatically after bootstrap, project-owned state is protected, and even script updates need review.
- STEP plans and substep prompts now remind agents to calibrate implementation work to the user's recorded experience level, not only architecture-session interviews.
- README and website quickstarts now lead with the direct clone flow and clarify GitHub template setup.
Fixed
status.shnow ignores HTML-commented example STEP rows so the next-action resolver does not treat documentation examples as real roadmap state.- Bootstrap no longer leaves Throughstone's root README and changelog in generated projects.
- Mono-repo bootstrap now reuses a non-Throughstone root
origin, while multi-repo workspaces remain detached until the user chooses remotes. - Successful bootstrap remotes are recorded in
repos.ymlsosetup-workspace.shcan clone sibling repos later. - The method-check workflow can locate
check.shin both multi-repo and mono-repo layouts. - Session 1.1's conditional-session summary includes privacy/compliance alongside native app and identity/auth.