Skip to content

the marketplace submodule is pinned behind the corpus's served head — the recipe pages are generated from an old corpus #201

Closed
#203
Closed
the marketplace submodule is pinned behind the corpus's served head — the recipe pages are generated from an old corpus#201
#203
Assignees
aitrawog

Description

@aitrawog
aitrawog
opened on Oct 29, 2026

The marketplace submodule is pinned behind the corpus's served head — the recipe pages are generated from an old corpus

What is measured

This repo carries the corpus as a submodule (marketplace/), and the generation workflow
clones the pinned charly, regenerates the site's generated half, and FAILS on any drift
between the committed pages and what the pinned sources produce.

The pinned corpus commit (5feb9c8b8350849fd2d46d252b486844c18bd0a4) is 8 commits behind
the corpus repo's main head, measured 2026-10-29 at
197f42a57ab88fcaed6a044bf312d753a72062b2 (tag v2026.302.0622). So the
recipes/** pages — the projection of the corpus — are generated from a corpus that the
corpus repo has moved past.

One consequence is visible in the tree. The published page still teaches the corpus's
drift gate's OLD instrument:

$ git grep -n 'git status --porcelain' -- . | grep -v CHANGELOG
src/content/docs/recipes/internals/marketplace.md:66:regenerated files (`git status --porcelain`, not just `git diff --exit-code`). A refs

The corpus's own projection of the same skill now says the gate deliberately does NOT use
that command (opencharly/plugin-marketplace#56 tracks that sentence's own fix). The mirror
is one corpus advance behind, and this page is where it shows.

This is invisible to the drift gate, by construction. The gate compares the committed
pages with what the PINNED sources regenerate, and the pinned sources regenerate their own
(old) pages perfectly. The repo's own workflow says so in its commit: the pinned inputs'
currency is REPORTED, never failed, because the remedy for a stale pin is a regeneration PR
that bumps the pin — not a gate that fails.

RCA

  • Mechanism: the corpus repo's daily refresh advances the corpus's main; this repo's
    submodule gitlink does not move with it. Nothing in this repo's gates compares the
    pinned corpus commit with the corpus's served head.
  • Missed control: the pin-currency comparison against the corpus's main. The repo's
    workflow REPORTS each pinned input's currency — the machinery exists — but the report is
    a notice, and the pin is only advanced by a human-authored regeneration PR.
  • Blast radius: the published site's recipe/reference pages project a corpus that is
    behind the published corpus. Every corpus advance that is not carried here silently
    leaves the site one refresh behind, and nothing in the tree says so.
  • Root fix: bump the marketplace submodule to the corpus's main head and carry the
    REGENERATED pages in the same change — the regeneration is what proves the bump is
    coherent (a stale submodule plus regenerated pages from the new corpus would drift).

Relation to #199

#199 is about the release-TAG class of pins — the generator's own tag and the 65
wiring-candy plugin tags — and about them being unobserved. This issue is the corpus
SUBMODULE: a gitlink to the corpus repo's commit, the input the recipe pages are
generated from. The two are different pin classes with different remedies, so they are
tracked separately.

Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0

Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (analysed on a live system)

Activity

  1. aitrawog commented on Oct 29, 2026

    @aitrawog
    aitrawog
    on Oct 29, 2026
    ContributorAuthor

    CLAIM — this session takes #201.

    Scope. Advance the marketplace submodule gitlink from 5feb9c8b8350849fd2d46d252b486844c18bd0a4 to the corpus's served head 197f42a57ab88fcaed6a044bf312d753a72062b2 (tag v2026.302.0622, merged as b0b924ef in opencharly/marketplace#599), and carry the REGENERATED pages in the same change.

    Why the regeneration travels with the bump. A stale submodule plus pages generated from the NEW corpus would drift; the pages ARE the proof that the bump is coherent. The generator is the one this repo's workflow pins — plugin-docs v2026.289.0814 built from cmd/serve, charly at the workflow's CHARLY_PIN be7a505f, the umbrella at UMBRELLA_PIN 1c88fcf.

    Baseline already measured. The local pipeline is CI-faithful: a regeneration at the OLD pin is a byte-exact no-op against the committed tree (diff -rq = 0 over the whole content tree, 1726 generated pages cleared and rewritten, rc=0). So the diff this leg produces is attributable to the corpus bump alone.

    Relation to #199. #199 is the release-TAG class of pins (the generator's own tag and the 65 wiring-candy plugin tags). This is the corpus SUBMODULE — a different pin class with a different remedy, tracked separately. #143 (the drift gate red on main since 2026-09-29) is untouched by this leg and stays open.

    Work. In the session worktree .worktrees/docs-refresh/docs, branch feat/marketplace-submodule-bump.

    Next. Materialize the submodule at the new commit, regenerate, run the repo's own gate, open the PR.

    Next update. On the PR opening.

    Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0

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

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

  3. aitrawog commented on Oct 29, 2026

    @aitrawog
    aitrawog
    on Oct 29, 2026
    ContributorAuthor

    STATUS — the corpus submodule is bumped and the pages are regenerated; the PR is open.

    What is done. The marketplace submodule advances 5feb9c8b8350849fd2d46d252b486844c18bd0a4 → 197f42a57ab88fcaed6a044bf312d753a72062b2 (the head opencharly/marketplace's merged main serves — one commit above its tag v2026.302.0622, because tag-on-merge writes CHANGELOG/ after the tag), and the four generated recipe pages that the corpus projects are regenerated in the same change. Head 27ab818daa661629f7ae103958fb69858152b031, branch feat/marketplace-submodule-bump, PR #203.

    The four pages are the projection of exactly the four corpus bodies that changed between the two pins — internals/skills/marketplace, internals/skills/plugin/references/authoring-recipes, kubevirt/skills/kubevirt and tools/skills/docs-site — one for one.

    What the bump fixes that was visible. The published page still taught the corpus drift gate's OLD instrument, "including UNTRACKED regenerated files (git status --porcelain, not just git diff --exit-code)". That command aborts on the refresh job's own tree, because the refresh stages its regenerated corpus on purpose. The page now carries the corpus's corrected text, with the explanation of why the gate does not use that command. This is the last of the three surfaces of opencharly/plugin-marketplace#56 (the corpus copy landed with opencharly/marketplace#599).

    What is proved. A regeneration at the OLD pin is a byte-exact no-op against the committed tree (diff -rq = 0 over the whole content tree, 1726 generated pages cleared and rewritten), so the 4-page diff is attributable to the corpus bump alone. The drift gate is green on the committed tree, the pin-currency report answers cur for the corpus pin, and the site's own workflow gates — the step-deadline gate, the dependency-advisory gate (each with its self-test and its mutation harness), the pin-currency fixtures and the drift-gate fixtures — are all rc=0 with zero warnings. The site builds: npm ci rc=0, npm run build rc=0, 1749 pages, sitemap emitted, under the node version this repo pins (22.23.4).

    What is next. The validator's verdict on #203, read in full; every finding fixed in ONE commit per round; then the land, and this issue closed by hand (a bot merge never auto-closes a Closes #N).

    One separable finding is filed, not folded in. The charly CI-time pin is 2 commits behind charly's merged main — a different pin class, with its own producer and its own remedy. It is #202, with its RCA and its measured evidence, and it is not claimed by this session.

    Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0

    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 29, 2026

    docs(corpus): advance the corpus submodule to the corpus's served hea…

    6ff63d2

  5. aitrawog commented on Oct 29, 2026

    @aitrawog
    aitrawog
    on Oct 29, 2026
    ContributorAuthor

    RESOLVED — the corpus submodule is at the corpus's served head, the pages are regenerated, and the site is deployed.

    What landed. #203, merged 6ff63d2ab1f2062283d44dc940fbd72c5da17b3e at 2026-10-29T06:52:12Z, tagged v2026.302.0652. The marketplace submodule advances 5feb9c8b8350849fd2d46d252b486844c18bd0a4 → 197f42a57ab88fcaed6a044bf312d753a72062b2 — the head opencharly/marketplace's merged main serves, one commit above that repo's tag v2026.302.0622 because tag-on-merge writes CHANGELOG/ after the tag — and the four generated recipe pages that the corpus projects are regenerated in the same change.

    The gate, on the committed tree and independently in CI. The validator PASSed with no findings. The repo's own workflow then regenerated the site from the pinned inputs and found the committed tree byte-identical to what they generate:

    corpus pin: 197f42a57ab88fcaed6a044bf312d753a72062b2 is cur — at the corpus's merged main
charly pin: be7a505f476c1a5b0302d878e0b5686a2cde3e07 is behind — 2 commit(s) behind charly's merged main
umbrella pin: 1c88fcf15f8fb9dd8b2814210472a63d3a79d0e2 is cur — at the umbrella's merged main
check-dependency-advisories: OK (no known advisory in the production tree or the dev tree)
content: committed tree matches the pinned inputs (regeneration is a no-op).
[build] 1749 page(s) built in 55s
[build] Complete!

    The attribution was measured before the bump: a regeneration at the OLD pin is a byte-exact no-op against the committed tree (diff -rq = 0 over the whole content tree, 1726 generated pages cleared and rewritten), so the four-page diff is attributable to the corpus bump alone.

    The symptom this issue was filed for is gone. The published page taught the corpus drift gate's OLD instrument — "including UNTRACKED regenerated files (git status --porcelain, not just git diff --exit-code)". That command aborts on the refresh job's own tree, because the refresh stages its regenerated corpus on purpose. The corpus's own copy was already corrected (opencharly/marketplace#599); the site's copy now carries the same corrected text, and the claim-keyed sweep over src/ finds no surviving instance of the retired sentence.

    This issue is closed by hand. A merge performed by github-actions[bot] does not close a Closes #N, so the closure is deliberate, with the evidence above.

    One separable finding was filed, not folded in. The charly CI-time pin is 2 commits behind charly's merged main — a different pin class, with its own producer and its own remedy. It is #202, with its RCA and its measured evidence, and it is not claimed by this session.

    Agent: charly · session ses_8efb271d-f2c0-47d3-85e3-2a1e00b11ae0

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

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