Skip to content

the vendored corpus pin is 6 commits behind the marketplace's merged main, so the published internals recipes are a stale projection #195

Closed

Description

@aitrawog

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=0

ahead=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:5

The live site publishes NONE of it:

$ curl -s --max-time 30 "https://opencharly.ai/recipes/internals/git-workflow/" | grep -o ':(literal)' | wc -l
0

So 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

  1. advance this repo's marketplace submodule to the corpus's merged main;
  2. carry the regenerated pages — the recipes/** half of the site projects the corpus, so the regenerated recipes/internals/git-workflow/** pages change with it, and the repo's generation workflow's drift gate is what proves they were carried;
  3. 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 charly repo'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

  1. aitrawog commented on Oct 28, 2026

    @aitrawog
    ContributorAuthor

    CLAIM — the consumer leg of the corpus's merged main.

    Taking this leg: advance this repo's marketplace pin from 835d0998 to the corpus's merged main 99a1bb4a6f (a fast-forward, ahead=6 behind=0), and carry the regenerated pages.

    Why this leg is mine to take. The corpus's ## Consumers table names two consumers: opencharly/opencharly (landed as opencharly/opencharly#762, whose pin is now 99a1bb4a6f) and opencharly/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.

    1. branch feat/corpus-pin-corpus99 off this repo's fresh origin/main, in a session worktree;
    2. advance the marketplace submodule through the submodule's own remote-tracking path (git submodule update --remote marketplace — the pin follows the branch .gitmodules declares), never a hand-set gitlink;
    3. regenerate the generated half with the workflow's OWN pinned inputs — the pinned charly at bafd8dbc, the pinned umbrella at e631aacf, the pinned plugin-docs at v2026.289.0814 built from its own tag, and the corpus wiring candy written by .github/docs-corpus/build_wiring.py — and carry the resulting pages;
    4. run this repo's own gate on the committed tree: the regeneration, the drift check, the corpus-currency report and the Astro build;
    5. open the PR, read every comment and the validator's full report, one commit per round; close this issue by hand with a RESOLVED record when it lands.

    STATUS follows at each milestone.

    Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

  2. self-assigned this
    on Oct 28, 2026
  3. aitrawog commented on Oct 28, 2026

    @aitrawog
    ContributorAuthor

    STATUS — the pin is advanced in the session worktree; the regeneration is running against the workflow's own pinned inputs.

    Done so far.

    • The worktree is up: .worktrees/corpus99/docs, a clone of this repo alone, on feat/corpus-pin-corpus99, branched from this repo's fresh origin/main (39203ee).
    • The pin is advanced through the submodule's own remote-tracking path — git submodule update --remote marketplace — and the index now carries 160000 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).
    • The generation inputs are materialized exactly as .github/workflows/deploy.yml pins them, measured from the workflow file itself: the charly source at bafd8dbc3110904872831998fb4caa701cc2990c (with its box/* submodules at the commits that checkout records), the umbrella at e631aacf32df4e26a66f2cb6a75fc9e85e212399, and the plugin-docs CLI built from v2026.289.0814 (e9d461d9cfb9a82d6e8042017b9660baefcc16b8) in this session — not a shared install.
    • The dependency-advisory gate is green on this tree: 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):

    corpus pin: 835d099845cd51ac90f6677179d750fbb384fc83 is behind — 6 commit(s) behind the corpus's merged main; an advance available NOW (a pin-bump PR in this repo) (merged main: 99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417)
    

    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-2a1e00b11ae0
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

  4. aitrawog commented on Oct 28, 2026

    @aitrawog
    ContributorAuthor

    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.

    • The PR is open against this repo: docs(corpus): advance the vendored corpus pin to the corpus that carries the pathspec rule, and regenerate #197, branch feat/corpus-pin-corpus99, head 99161e37b27a98244953431f3ddc2d221a2a4c79, branched from this repo's fresh origin/main (39203ee).
    • The pin moved through the submodule's own remote-tracking path — git submodule update --remote marketplace — and the index carries 160000 99a1bb4a6f10112f67e3ddd73d3e86b3f6bc3417 marketplace: the corpus's merged main tip, 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.
    • The six pages the pin projects are carried in the same commit, and no page is hand-edited — they are the generator's output for the advanced pin.
    • The gate is green on the committed tree: the regeneration is a no-op, the drift gate reports content: committed tree matches the pinned inputs (regeneration is a no-op), the corpus-currency report changed from behind — 6 commit(s) to cur, 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):

    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-2a1e00b11ae0
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

  5. aitrawog commented on Oct 28, 2026

    @aitrawog
    ContributorAuthor

    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, CHANGELOG 2026.301.0410.

    What the issue asked for. The issue named the defect exactly: the marketplace pin was 6 commits behind the corpus's merged main, 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 merged main tip, a MERGED ref, advanced through the submodule's own remote-tracking path (git submodule update --remote marketplace, the path .gitmodules' branch = main declares), never a hand-set gitlink. The six regenerated recipes/internals/git-workflow* pages carry the corpus's advance, and the corpus's own consumer report now reads this repo as cur:

    $ bash scripts/consumer-currency.sh
    consumer-currency: 2 consumer(s) read, 0 behind, 0 not-on-the-served-line, 0 undecidable, 0 unreadable (merged main: 99a1bb4)
      opencharly/docs  marketplace  99a1bb4  cur — at the corpus's merged main

    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 is cur, 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.md entry 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 charly and 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 on main) 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-2a1e00b11ae0
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions