Repository navigation
feat(tools): read a fork's own manifest keys and its fork_core additions - #1970
Merged
Merged
Conversation
Part of #1944: after the split a fork must move its templates out of the keys upstream owns, and the resolver read only five fixed keys. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Part of #1944 (a prerequisite the split exposed).
The gap. After the fork merges the split with
-s ours, about 33 moved templates sit underbase:andbackend:, andbase-readmesits incore:. ADR-049 rule 4 and SYS-20 forbid a fork to edit those keys. Rule 4 already lets a fork append "keys of its own", butresolve.pyand smoke read five fixed keys, so a fork's template under its own key resolved as a missing dependency. A fork had no legal place to keep its templates.Change:
resolve.pygainsentry_sections(manifest), which returns every top-level list of entries exceptversion,coreandfork_core, andcore_tier(manifest), which returnscorefollowed by a fork'sfork_core.load_manifestuses both.run_smoke.pyimports the same two functions for_load_manifest, SYS-03 and SYS-04, so there is one definition of a section.acme:key andfork_core:through the resolver's CLI, and asserts the chain carries the upstream core file, the fork's dependency and the fork's core addition. SYS-19's loop is extracted into_resolve_casesand shared.fork_core:". The SPEC core-tier section and the manifest header say the same.Control: with main's
resolve.py, the SYS-21 manifest exits 1 withMissing dependency: stack-fork depends on fork-lib, which has no manifest entry. With this branch it resolvesquality.md,docs.md,git.mdand the stack.Test changes: SYS-19's assertions are unchanged; only its loop moved into a helper. SYS-21 is new.
Local (Git Bash): smoke 36/36, conformance 24 / 0 failed, fork sync 3/3 (nested smoke 36/36), sync, resolve and redundancy clean. Upstream's own manifest has no fork key, so every chain is unchanged (
resolve.py --checkclean).🤖 Generated with Claude Code