Repository navigation
the vendored corpus pin is 6 commits behind the marketplace's merged main, so the published internals recipes are a stale projection #195
Description
The docs site publishes a corpus pin that is 6 commits behind the corpus's merged main, and the guidance it publishes from that pin is stale in a way a reader can act on wrongly — on the live public site, not only in the tree.
The pin, and the advance available NOW
Measured against the REMOTE (the pin's intent is a leaf — upstream:main, implicit from .gitmodules' branch= — so the remote is the judge, not a hand-built comparison table):
$ git ls-tree HEAD marketplace
160000 commit 835d099845cd51ac90f6677179d750fbb384fc83 marketplace
$ git ls-remote https://github.com/opencharly/marketplace.git refs/heads/main
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417 refs/heads/main
$ gh api "repos/opencharly/marketplace/compare/835d099845cd51ac90f6677179d750fbb384fc83...99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417" --jq '"status=\(.status) ahead=\(.ahead_by) behind=\(.behind_by)"'
status=ahead ahead=6 behind=0ahead=6, behind=0 — the served tip DESCENDS from the recorded pin, so this is a fast-forward advance available NOW, not a divergence. A leaf's behind is a REPORT-and-PASS state (the umbrella's AGENTS.md Part II #3): it does not gate, and it is not a failure. It is the next leg of a cross-repo sequence, and this leg takes it.
The six commits, in order:
$ git -C marketplace log --format='%h %s' 835d099845cd51ac90f6677179d750fbb384fc83..99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417
99a1bb4 docs: add CHANGELOG 2026.301.0245 for PR #585
cf03091 chore(refs): advance the umbrella pin to v2026.301.0144 and regenerate the corpus (#583) (#585)
b920b01 docs: add CHANGELOG 2026.300.2310 for PR #582
c33e662 chore(refs): advance the umbrella pin to v2026.300.2229 and regenerate the corpus (#582)
aa98c12 docs: add CHANGELOG 2026.300.1328 for PR #581
bee9acd chore(refs)!: the last two carrier refs drop, and the three pins that carry their bodies advance (#581)What the stale corpus publishes — and it is LIVE
The corpus's internals family is the projection of the umbrella's own .agents/ tree, and this repo's pin decides which projection the site serves. The org's guidance has since gained a pathspec rule — a path argument is a PATHSPEC, */?/[ match several paths, a leading : matches nothing, both silently with exit 0 — and the rule's remedy is the LITERAL form, written after a -- separator:
$ git -C marketplace grep -c ':(literal)' 835d099845cd51ac90f6677179d750fbb384fc83 -- internals/ | wc -l
0
$ git -C marketplace grep -c ':(literal)' 99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417 -- internals/
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417:internals/agents/pr-validator.md:2
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417:internals/skills/git-workflow/SKILL.md:3
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417:internals/skills/git-workflow/references/branch-and-pr-loop.md:4
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417:internals/skills/git-workflow/references/multi-repo-coordination.md:8
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417:internals/skills/git-workflow/references/umbrella-mechanics.md:5The live site publishes NONE of it:
$ curl -s --max-time 30 "https://opencharly.ai/recipes/internals/git-workflow/" | grep -o ':(literal)' | wc -l
0So a reader of the published site is told to run git ls-tree <head> <sub> and git -C <repo> grep ... -- <path> — the very forms the new guidance measures as silently wrong (a * in a path matches SEVERAL paths; a leading : matches NOTHING; both exit 0) — and the site never mentions the ':(literal)<path>' form that fixes it. The rule is not cosmetic: the corpus's own pr-validator roster says that one command has "THREE independent ways to return a confident wrong number", and its remedy is exactly the form this site does not publish.
The producer is landed; this repo is the consumer leg
The producer is merged and tagged: opencharly/marketplace#585 (the chore(refs) leg) with its tag-on-merge record commit 99a1bb4a6f. The umbrella's own consumer leg of the same corpus advance has landed as opencharly/opencharly#762 — its marketplace pin is now 99a1bb4a6f — so the corpus's advance is the producer's tip and the umbrella is already there. This repo is the remaining consumer: the corpus's own ## Consumers table names exactly two, opencharly/docs (pin path marketplace) and opencharly/opencharly (landed).
The producer-first order is producer PR → merge → tag → consumer pin bump. This repo's own AGENTS.md says it: "Generated pages are never edited here … Edit the source, then land a regeneration PR here that bumps the pinned charly commit — and, for a corpus change, the pinned marketplace commit — and carries the regenerated pages."
The fix, and its scope
- advance this repo's
marketplacesubmodule to the corpus's merged main; - carry the regenerated pages — the
recipes/**half of the site projects the corpus, so the regeneratedrecipes/internals/git-workflow/**pages change with it, and the repo's generation workflow's drift gate is what proves they were carried; - the drift gate runs the regeneration on the committed tree and fails on any difference, including untracked files.
The generated pages are never hand-edited: they are the corpus's own text, projected.
What this issue does NOT claim
- It does not claim the site's charly pin is stale. That pin is the CI-time commit in
.github/workflows/deploy.yml, and this leg does not move it. - It does not claim the deployed site is BROKEN: the pages the site serves are a faithful projection of the corpus it pins. The defect is that the corpus it pins is an advance behind, and the corpus's own consumer report says so.
- It does not claim anything about the
charlyrepo's own docs sources, and it changes no hand-authored page.
Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
Activity
aitrawog commentedon Oct 28, 2026
CLAIM — the consumer leg of the corpus's merged main.
Taking this leg: advance this repo's
marketplacepin from835d0998to the corpus's merged main99a1bb4a6f(a fast-forward,ahead=6 behind=0), and carry the regenerated pages.Why this leg is mine to take. The corpus's
## Consumerstable names two consumers:opencharly/opencharly(landed as opencharly/opencharly#762, whose pin is now99a1bb4a6f) andopencharly/docs— this repo. The producer leg (opencharly/marketplace#585) is merged and tagged, so the order allows the consumer leg now. No other open PR or issue in this repo touches the corpus pin, and no other session's branch, worktree or file is in scope.The plan, in the order it happens.
feat/corpus-pin-corpus99off this repo's freshorigin/main, in a session worktree;marketplacesubmodule through the submodule's own remote-tracking path (git submodule update --remote marketplace— the pin follows the branch.gitmodulesdeclares), never a hand-set gitlink;charlyatbafd8dbc, the pinnedumbrellaate631aacf, the pinnedplugin-docsatv2026.289.0814built from its own tag, and the corpus wiring candy written by.github/docs-corpus/build_wiring.py— and carry the resulting pages;STATUSfollows at each milestone.Agent: charly · session
ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 28, 2026
STATUS — the pin is advanced in the session worktree; the regeneration is running against the workflow's own pinned inputs.
Done so far.
.worktrees/corpus99/docs, a clone of this repo alone, onfeat/corpus-pin-corpus99, branched from this repo's freshorigin/main(39203ee).git submodule update --remote marketplace— and the index now carries160000 99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417 marketplace(the corpus's merged main, the tag-on-merge record commit for chore(refs): advance the umbrella pin to v2026.301.0144 and regenerate the corpus (#583) marketplace#585)..github/workflows/deploy.ymlpins them, measured from the workflow file itself: thecharlysource atbafd8dbc3110904872831998fb4caa701cc2990c(with itsbox/*submodules at the commits that checkout records), the umbrella ate631aacf32df4e26a66f2cb6a75fc9e85e212399, and theplugin-docsCLI built fromv2026.289.0814(e9d461d9cfb9a82d6e8042017b9660baefcc16b8) in this session — not a shared install.check-dependency-advisories: OK (no known advisory in the production tree or the dev tree).The currency report, before the bump — this is the only thing in the repo that can see a corpus that trails its own merged main (the PINNED corpus regenerates its own old pages perfectly, so the drift gate is blind to it):
Next. The regeneration is running now (it resolves the corpus's carriers and re-projects the recipes), then the pages are carried in one commit, the gate runs on the committed tree — regeneration, drift check, currency report, Astro build — and the PR opens. Next update when the PR is open.
Agent: charly · session
ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 28, 2026
STATUS — the corpus leg is open for review: the pin is advanced, the pages are carried, and the gate is green on the committed tree.
Done.
feat/corpus-pin-corpus99, head99161e37b27a98244953431f3ddc2d221a2a4c79, branched from this repo's freshorigin/main(39203ee).git submodule update --remote marketplace— and the index carries160000 99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417 marketplace: the corpus's mergedmaintip, the tag-on-merge record commit for chore(refs): advance the umbrella pin to v2026.301.0144 and regenerate the corpus (#583) marketplace#585, and the same commit the umbrella's own corpus pin now holds.content: committed tree matches the pinned inputs (regeneration is a no-op), the corpus-currency report changed frombehind — 6 commit(s)tocur, the drift gate's own test runs 6 tests OK, the dependency-advisory gate is OK, and the Astro build built 1699 pages. Every step exited 0, zero warnings.The claim, measured on both sides. The rule's literal form — the string the new guidance tells a reader to write — is 0 occurrences in the whole published
recipes/tree this repo served before, and 0 on the live site; it is present in the pages the site serves after, because this repo's pin is what decides which projection is served.Three findings filed or fed, none blocking this leg (each is in the PR's
## Filed issues):charly91 commits, the umbrella 373) and nothing reports it: this repo's currency report watches the corpus only. Filed and claimed; it is its own cutover.main(the org ruleset requiresvalidate / validateand nothing else). Today's evidence is added to that thread, together with the measurement that the symptom it opened with — the regeneration droppingplugin-docs/plugin-pipeline/plugin-review— no longer reproduces.overridesentry breaks the CI'snpm ci#190 — the npm that resolves the lockfile is undeclared, and this leg's local build ran npm11.20.0while CI runs npm10.9.9. The measurement is added to that thread, and the versions this build ran under are in the PR's How tested.Next. The validator's verdict, read in full, and every finding it raises fixed in one commit per round. Next update when the verdict lands, or when the round's fixes are pushed.
Agent: charly · session
ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 28, 2026
RESOLVED — the corpus pin is advanced and the site publishes the pathspec rule's remedy.
Landed. #197 — squash
98a5f6cbfb4d659d28c1ec15804f70f6b1d75783, merged 2026-10-28T04:10:09Z, CHANGELOG2026.301.0410.What the issue asked for. The issue named the defect exactly: the
marketplacepin was 6 commits behind the corpus's mergedmain, so every published internals recipe was a projection of a corpus the org had already replaced, and the site's own drift gate could not see it — the pinned corpus regenerates its own old pages perfectly, so a stale pin is invisible to it.What landed. The pin moved to
99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417— the corpus's mergedmaintip, a MERGED ref, advanced through the submodule's own remote-tracking path (git submodule update --remote marketplace, the path.gitmodules'branch = maindeclares), never a hand-set gitlink. The six regeneratedrecipes/internals/git-workflow*pages carry the corpus's advance, and the corpus's own consumer report now reads this repo ascur:The claim, measured at both ends. The rule's literal form — the string the new guidance tells a reader to write — was absent from the pages this repo served before the change and is present in four of the six regenerated pages after it, with a calibration arm (the retired form's own line still returned by the same key at the old pin, and by nothing at the new one), so the empty "before" is evidence rather than a coincidence.
The gate, on the committed tree. The regeneration is a no-op against the committed tree (
content: committed tree matches the pinned inputs), the corpus-currency report iscur, the drift test runs 6 tests OK, the dependency-advisory gate is clean, and the Astro build assembles 1699 pages — every step exit 0, zero warnings.One correction to the record, in full on the PR. The validator's PASS armed native auto-merge 36 seconds before the squash landed, so a body edit carrying the fix for its non-blocking observation could not reach the server. The observation is confirmed and fixed in the derivation; the corrected per-file table and the full RCA are on #197 (comment 6460499537). The landed
CHANGELOG/2026.301.0410.mdentry is not edited — a merged changelog entry is immutable by the org's own rule — and the change itself, the pin and the pages are unaffected.Still open, filed, and separable — not closed by this issue. #196 (the site's own
charlyand umbrella pins are 91 and 373 commits behind, and the repo's currency report watches only the corpus), #143 (the drift gate is still not a required check onmain) and #190 (the repo declares its node but not the npm that resolves its lockfile). Each carries its own measurement and its own owner.Agent: charly · session
ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)