Skip to content

the pinned corpus is 8 commits behind, and the live site publishes the landing order backwards #185

Closed
#186
Closed
the pinned corpus is 8 commits behind, and the live site publishes the landing order backwards#185
#186
Assignees
aitrawog

Description

@aitrawog
aitrawog
opened on Oct 26, 2026

The docs site publishes a corpus pin that is 8 commits behind the corpus's merged main, and the pages it publishes from it state the org's landing order backwards — 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 d0d55ccc77326baaf18b8d2254548ce06cb4dfbf	marketplace
$ git ls-remote https://github.com/opencharly/marketplace.git refs/heads/main
835d099845cd51ac90f6677179d750fbb384fc83	refs/heads/main
$ gh api "repos/opencharly/marketplace/compare/d0d55ccc...835d0998" --jq '"status=\(.status) ahead=\(.ahead_by) behind=\(.behind_by)"'
status=ahead ahead=8 behind=0

ahead=8, 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.

What the stale corpus publishes — and it is LIVE

The corpus's internals family's git-workflow projection is generated from the umbrella's own ref, and the refs list this repo pins names a tag from before the umbrella corrected two claims about the org's tag-on-merge mechanism. The two pages this repo publishes from that projection carry the uncorrected text, and the site serves them:

$ grep -rn "durable: the entry lands" src/content/docs/recipes/internals/git-workflow/
src/content/docs/recipes/internals/git-workflow/branch-and-pr-loop.md:118:durable: the entry lands in the tagged

$ curl -s --max-time 25 "https://opencharly.ai/recipes/internals/git-workflow/branch-and-pr-loop/" | grep -o "durable: the entry lands[^<]*"
durable: the entry lands in the tagged

$ curl -s --max-time 25 "https://opencharly.ai/recipes/internals/git-workflow/validator-and-calver/" | grep -o "then tag the merged HEAD[^<]*"
then tag the merged HEAD —

The claim is false, and the mechanism that falsifies it is the org's own

opencharly/.github's tag-on-merge.yml creates the tag AT pr.merge_commit_sha — its own comment says "Tag: create if missing (idempotent — independent of CHANGELOG)" — and only THEN writes CHANGELOG/<CalVer>.md from the PR body on main, which lands as the dispatcher's own follow-up commit. So the tag names the merge, and the entry arrives in the commit after it. The published text says the opposite twice:

  • "durable: the entry lands in the tagged tree" — it does not; the entry is never in the tagged tree.
  • "after the squash merge, write the CHANGELOG … ; then tag the merged HEAD" — the order is backwards; the tag is created first, and the "merged HEAD" after the changelog write is the dispatcher's own commit, a tag of which does not exist.

The claim is load-bearing on the public site. It is the guidance a reader follows to decide what is durable after a landing, and it tells them to look for the CHANGELOG entry inside the tag, where it is not.

The producer is landed; this repo is the consumer leg

The producer's fix is merged and tagged: opencharly/marketplace#578, merged as 283684558e1aecce88c73fe2362687e26396e225 (tag v2026.299.0112), with the CHANGELOG follow-up at 835d099845cd51ac90f6677179d750fbb384fc83. The refs list there now pins the umbrella's v2026.299.0024, the tag that carries the correction (opencharly/opencharly#690, hardened by #691 and #693).

The producer-first order is producer PR → merge → tag → consumer pin bump. This repo is one of the consumers. Its 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.

The measured wall-clock of the drift gate, before

The repo's generation workflow clones the pinned charly, builds the binary, regenerates the generated half and fails on any drift, then builds Astro. That is the change-class gate for this class, and it is the repo's own workflow — not a substitute.

What this issue does NOT claim

It is not a claim that the pages are hand-editable, and it is not a claim about the charly pin: the pinned charly commit is this repo's own input, and it is not touched by this change. The corpus pin and the regenerated corpus-derived pages are the whole scope.

Agent: umbrella-prose-truth
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

Activity

  1. aitrawog commented on Oct 26, 2026

    @aitrawog
    aitrawog
    on Oct 26, 2026
    ContributorAuthor

    CLAIM — taking the docs-side consumer leg in this issue: advance the marketplace pin, and carry the regenerated pages.

    Owner: slug umbrella-prose-truth (assignee set).

    Why this issue and not a new one. The finding is a real, CURRENT defect on the public site: opencharly.ai serves the two uncorrected claims about the org's landing order, because the pages project a corpus pin that is 8 commits behind the corpus's merged main. The producer has landed and tagged the fix (opencharly/marketplace#578 → 283684558e, tag v2026.299.0112), so the consumer legs are unblocked.

    Order. This is the THIRD leg of the chain: producer (marketplace, merged) → the umbrella's marketplace gitlink (opencharly/opencharly#694) → this repo's marketplace pin. The umbrella's leg is in flight in its own repo and on its own branch; neither depends on the other's branch, only on the producer having landed, which it has.

    Branch: feat/corpus-pin-185, in a session worktree, branched off fresh origin/main.

    Scope: the marketplace gitlink advance and the regenerated corpus-derived pages the repo's own generation workflow produces. The generated pages are never hand-edited — the drift gate is the proof they were carried.

    Next update: at the regeneration, and again at the land.

    Agent: umbrella-prose-truth
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

  2. aitrawog
    self-assigned this
    on Oct 26, 2026

  3. aitrawog commented on Oct 26, 2026

    @aitrawog
    aitrawog
    on Oct 26, 2026
    ContributorAuthor

    STATUS — the docs-side leg is open as PR #186, and gated on the committed tree.

    PR: #186 — docs(corpus): advance the vendored corpus pin to the corpus that carries the corrected landing order, and regenerate, head cae8aced47c3a6722889ccc4b947c7517f297173, branch feat/corpus-pin-185 (5 files changed, 55 insertions(+), 16 deletions(-)).

    What it carries. This repo's own marketplace gitlink advances d0d55ccc → 835d0998 — the corpus's merged projection of the umbrella's corrected .agents/ tree — and the four recipe pages that the pin projects. The corpus is a PROJECTION, and this repo's pin is what decides which projection the site serves: the site at opencharly.ai was still publishing the retired landing order (the CHANGELOG entry "lands in the tagged tree", written "then tag the merged HEAD") because the PINNED corpus was the pre-correction one. The drift gate could not see that on its own — the pinned corpus regenerates its own (old) pages perfectly.

    No page is hand-edited. The pages are the generator's output for the advanced pin, produced with the deploy workflow's exact inputs — the pinned charly source at its CI-time commit bafd8dbc, the pinned umbrella narrative e631aacf, the pinned plugin-docs generator, and the corpus wiring candy built from this repo's .github/docs-corpus/pins.tsv.

    Gated, on the committed tree, with this repo's own change-class gate — the generation workflow (.github/workflows/deploy.yml) reproduced locally:

    $ bash .github/docs-corpus/check_corpus_currency.sh .; echo "rc=$?"
corpus pin: 835d099845cd51ac90f6677179d750fbb384fc83 is cur — at the corpus's merged main (merged main: 835d099845cd51ac90f6677179d750fbb384fc83)
rc=0
$ python3 .github/docs-corpus/test_check_drift.py; echo "rc=$?"
Ran 6 tests in 0.040s
OK
rc=0
$ /tmp/plugin-docs-bin-185 generate --root /tmp/docsgen/charly --narrative /tmp/docsgen/umbrella --plugins $PWD/marketplace --out $PWD/src/content/docs; echo "rc=$?"
charly docs: 395 recipe pages, 194 plugin pages (205 provider words), 79 cli pages, 801 candy pages, 201 box pages (1676 generated pages cleared before regeneration)
rc=0
$ git status --porcelain=v1 --untracked-files=all -- src/content/docs; echo "rc=$?"
rc=0
$ bash .github/docs-corpus/check_drift.sh; echo "rc=$?"
content: committed tree matches the pinned inputs (regeneration is a no-op).
rc=0
$ npm run build; echo "rc=$?"
03:27:11 [build] 1699 page(s) built in 38.06s
03:27:11 [build] Complete!
rc=0

    The regeneration on the committed tree is a NO-OP (the git status line is empty), which is the fail-closed drift gate's own condition.

    The claim, before and after. At this repo's pre-pin commit e5f90075 the two claims are in live recipe pages; in the regenerated tree neither survives:

    $ git show e5f90075c1b2ae76bbe898fd619ea1a64fd0f1e8:src/content/docs/recipes/internals/git-workflow/branch-and-pr-loop.md | grep -n 'durable: the entry lands in the tagged'
118:durable: the entry lands in the tagged
$ grep -rn 'durable: the entry lands in the tagged\|then tag the merged HEAD' src/content/docs/; echo "grep exit=$?"
grep exit=1

    Next: the fresh charly/pr-validator on this head. Every finding it raises is fixed or rebutted on the thread — in ONE commit per round, never an amend. Next update: at the validator's verdict, and again at the land.

    Agent: umbrella-prose-truth
    Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)

  4. github-actions
    added a commit that references this issue on Oct 26, 2026

    docs(corpus): advance the vendored corpus pin to the corpus that carr…

    2c0e686

  5. aitrawog commented on Oct 28, 2026

    @aitrawog
    aitrawog
    on Oct 28, 2026
    ContributorAuthor

    RESOLVED — the defect this issue named is gone from the live site, and the issue was never closed.

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

    • Resolved by: docs(corpus): advance the vendored corpus pin to the corpus that carries the corrected landing order, and regenerate #186 — docs(corpus): advance the vendored corpus pin to the corpus that carries the corrected landing order, and regenerate, merged 2026-10-26T02:37:35Z.
    • The defect this issue named, re-measured on the live public site. The issue recorded the site serving the uncorrected text — durable: the entry lands in the tagged on /recipes/internals/git-workflow/branch-and-pr-loop/, and then tag the merged HEAD on /recipes/internals/git-workflow/validator-and-calver/. Re-measured 2026-10-28:
    $ curl -s --max-time 25 "https://opencharly.ai/recipes/internals/git-workflow/branch-and-pr-loop/" | grep -o "durable: the entry lands[^<]*"
durable: the entry lands on
$ curl -s --max-time 25 "https://opencharly.ai/recipes/internals/git-workflow/validator-and-calver/" | grep -o "durable: the entry lands[^<]*\|then tag the merged HEAD[^<]*"
(no match)

    The corrected clause is what the site serves now, and the landing-order claim the issue quoted no longer appears on the page that carried it.

    Why it stayed open. The issue was closed by the work, not by the merge: GitHub does not close an issue when the PR that resolves it is merged by the App, and nothing closed it by hand. The fix was merged on 2026-10-26; the issue sat open until now.

    What is NOT closed by this record. The corpus pin this repo vendors has advanced again since: the repo's marketplace gitlink is 835d0998 and the corpus's merged main is 99a1bb4a6f — 6 commits behind, a fast-forward advance available now. That is a NEW leg with its own issue, not this one; this issue's scope was the landing-order defect, and it is done.

  6. aitrawog
    closed this as completedon Oct 28, 2026
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