The stack layer becomes an adopter of the standard it belongs to - #2
Merged
Conversation
This repository published a technology layer for the standard without carrying the standard itself: no version pin, no manifest copy, no agent entry point, no specs, no decision log. The core's decision on satellite stacks names it the first genuinely aligned adopter once it pins a version, and it never did. It now carries the pin, the manifest copy, the shipped guards and skills, an agent entry point, a persona roster, four capability specs with the map that couples them to what they describe, a work ledger and a decision log. Drift went from 18 to 5 against the merged manifest; the built-in skeleton had been reporting 5 while warning that the real distance was larger, and it was - by more than three times. The five that remain are the technology layer's own entries, and they cannot be met here. They describe a repository that consumes this stack - biome.json, tsconfig.base.json, pnpm-workspace.yaml and vitest.config.ts at the root - while this repository publishes it and ships those files inside starter/. The stack-check-all guard runs pnpm check:all at a root with no package.json and fails outright. The manifest schema has no word for publisher versus consumer, and a guard cannot be waived by an exception by design, so no configuration of the shipped mechanism gets this repository to an honest zero. The options are in the backlog and none was taken here.
The check:all guard exits 1 with a message that is character for character what a guard reports when it ran and found three real lint errors. Nothing in the output distinguishes an unmet prerequisite from a genuine failure, so the number the report leans on cannot be read. The core is adding a field that lets a guard declare what it needs, and its inference already covers the package manager itself. The part inference cannot reach is the dependency tree: with the manager present and the tree absent, running the guard is what installs it - off the network, as a side effect of asking a question about a repository. Only the entry that knows the toolchain can name that, so it is recorded here with the exact declaration, blocked until the field exists to declare it against.
Every entry in the carried manifest declares core, and the copy carried no top-level profile field at all. The shipped workflow reads that field and falls back to scale when it is absent, so the coupling gate would have run blocking on a repository whose every entry asks for the advisory setting - and it would have done so silently, because no pull request has opened against this branch to reveal it. The field is the documented mechanism rather than a workaround: the manifest's own preamble says an adopted copy may carry it, written at alignment time, and that the verifier reads it as the default. The alignment simply did not write it. Core is the honest answer here. This repository has one maintainer, and the advisory setting is the one where the person who would fix a false positive is the person reviewing it. The recorded reading moves with it: four scale-only entries now leave both sides of the fraction, so the same five Layer 2 entries remain unmet against a smaller denominator.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This repository published a technology layer for the standard while carrying none of the standard itself: no version pin, no manifest copy, no agent entry point, no specs, no decision log. ADR-016 names it the first genuinely aligned adopter once it pins a version, and it never did.
What it carries now
The pin, the manifest copy, the shipped guards and skills,
AGENTS.md, a persona roster, four capability specs with the map that couples them to what they describe, a work ledger and a decision log.Capabilities were derived from what this repository actually is, not from a template:
stack-decisions(the picks),reference-implementation(starter/and its boot workflow),adoption-path(ADAPTING.md,QUICKSTART.md) andstack-contract(stack.manifest.json,SHIPPED.md). The Layer 1 files are$unclaimedon purpose - they are the standard's own content, and claiming them here would make every core update read as a change to a capability of this repository.Three measured numbers
drift 5 - 0% adopted (0/5)drift 18 - 71% adopted (44/62)drift 5 - 92% adopted (59/64)The skeleton warns in its own output that its number is not the real distance. It was understating by more than three times, which is worth knowing for every repository that reads it before adopting.
The five that remain, and why none of them is fixed here
Every remaining entry belongs to this repository's own stack manifest, and they describe a repository that consumes this stack -
biome.json,tsconfig.base.json,pnpm-workspace.yamlandvitest.config.tsat the repository root. This repository publishes the stack and ships those files insidestarter/, which is where they belong. Thestack-check-allguard runspnpm check:allat a root with nopackage.jsonand failsERR_PNPM_NO_IMPORTER_MANIFEST_FOUND.The manifest schema has no word for publisher versus consumer, and a guard cannot be waived by a manifest exception by design. So there is no configuration of the shipped mechanism under which this repository reaches an honest drift 0. Four options are written into
backlog.md(SELF-1) and none was taken - choosing one quietly would be the redefinition the standard exists to prevent.Two findings that fell out of the run
stack.manifest.jsononly inside a branch already guarded by the core manifest being present. Before this change, twelve stack file entries and one guard were read by nothing, while the published claim is one drift number across both layers. (SELF-2)WHAT-THIS-IS.mdsays eighteen,DECISIONS.mdhas seventeen numbered sections. Both are defensible: the table has 18 rows, section 10 covers three of them, and section 17 (monorepo layout) has no row at all. The wrong number is the symptom - the defect is that the table this document presents as its spine does not cover one of the picks. (SELF-6)Neither was "fixed" by adjusting prose.
scripts/facts-check.mjsnow ships here anddocs/facts.jsondoes not exist yet, which is the mechanism for making a restated count checkable rather than asserted.Verified
self-verify,spec-structure,decision-records-check --blockandspec-guard --audit --blockall run and pass here, each individually. Every relative link in the authored files was resolved against the filesystem.VERSIONuntouched; the changelog writes under## Unreleased.One authoring mistake worth recording rather than hiding: the persona roster was written from scratch instead of from the shipped template, so it lacked the
## The rosterheading the persona gate reads. The guard caught it and named the exact fix, which is the loop working.