Repository navigation
the site's corpus is behind the rule's new form: advance the vendored corpus pin to the corpus that carries it, and regenerate #181
Description
The site's corpus is behind the rule's new form: advance the vendored corpus pin and regenerate
This is leg D of a four-repo cutover (producer-first, AGENTS.md Part II #3). Leg A authored the sentence that describes the new rule (opencharly/layer-charly-internals, merged and tagged); leg B shipped the linter and the corpus it describes (opencharly/marketplace#569, merged 7bc431b, tag v2026.297.0356); leg C is the umbrella's gitlink bumps (opencharly/opencharly#653). This issue is the docs' leg.
What is stale
The site publishes the skill recipes from the vendored marketplace corpus, and the vendored pin is behind the corpus that carries this cutover's change. The ellipsis rule of the org's PR-body linter now has a form — it fires on the AUTHOR's elision (an elided $ command line, an elided head command's output, a dropped line of the paste) and ALLOWS a program's own token — and the sentence that says so is in the corpus. Until this leg lands, the published recipes teach the rule's old shape.
What changes
- The
marketplacegitlink advances to the corpus's merged main — the merge that carries the linter, the measurement instrument and the refs list that keeps the three drained internals skills published from their own repos rather than from a transitive twin (pr_body_lint's ellipsis rule cannot tell a program's own output from an author's ellipsis marketplace#537, a skill reached only through the closure publishes whatever tag a sibling names, silently: measured, image/skills/mise published 66 body lines from plugin-mise@v2026.274.2100 while the repo served 108 plugin-marketplace#41). src/content/docsis regenerated with the deploy workflow's exact inputs — the pinned charly source at its CI-time commit, the pinned umbrella narrative, the pinnedplugin-docsgenerator, and the corpus wiring candy built from.github/docs-corpus/pins.tsv— and the regenerated pages are committed in the same change, because the deploy workflow's drift gate is fail-closed: a regeneration on a clean tree must be a no-op.
The gate
The deploy workflow's own deploy job, on this PR: the drift-gate self-test, the regeneration, the drift gate, npm ci, the Astro build and the site verification. The local proof is the same commands with the same inputs, plus a SECOND regeneration on the committed tree that must be a no-op.
Related, and deliberately not in this scope
- The deploy workflow's regeneration step can hang and deadlock the validator's auto-merge arming (the deploy workflow's content-regeneration step hangs, and it deadlocks the validator's auto-merge arming #162) — a workflow defect, in this repo but not in this leg's content.
- The drift gate is still not a REQUIRED check on
main(deploy drift gate red on main: regeneration drops plugin-docs/pipeline/review — catalog membership is undeclared and the gate is not required #143) — the control gap, and it is why a red regeneration can merge.
Activity
aitrawog commentedon Oct 24, 2026
CLAIM
Taking this one: the docs' consumer leg of the ellipsis cutover, in a session worktree off fresh
origin/main(5e26799), on branchfeat/ellipsis-537-docs.What is done. Nothing yet — the claim comes before the work.
What is next. The
marketplacegitlink advances to the corpus's merged main (the merge that carries the linter and the refs list),src/content/docsis regenerated with the deploy workflow's exact inputs — the pinned charly source at its CI-time commit, the pinned umbrella narrative, the pinnedplugin-docsgenerator, the wiring candy built from.github/docs-corpus/pins.tsv— and the regenerated pages are committed in the same change, because the deploy workflow's drift gate is fail-closed.Producer-first. The producer is landed and tagged:
opencharly/marketplace#569, merge7bc431b, tagv2026.297.0356. Nothing here waits on a producer.One thing to watch, and it is this repo's own. The deploy workflow's regeneration step can hang (#162), and it deadlocks the validator's auto-merge arming when it does. That is why the local proof runs the regeneration with the same inputs BEFORE the push, rather than discovering it in CI.
Agent: charly
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 24, 2026
STATUS
The docs leg of the ellipsis cutover is open as a PR. Head
ab999e8e9179ab17fff1ab31a8b4b3ca264b9d57onfeat/ellipsis-537-docs; baseorigin/main5e2679908610feab7c83db3215af3f8419f779a1.Done
af08be9→42b8789— the corpus's merged main, which carries theellipsisrule's new form (pr_body_lint's ellipsis rule cannot tell a program's own output from an author's ellipsis marketplace#537, merge7bc431b, tagv2026.297.0356).git status --porcelain=v1 --untracked-files=all -- src/content/docsprinted no line at all), the drift gate (content: committed tree matches the pinned inputs (regeneration is a no-op)., exit 0), the drift gate's own self-test (6 tests, OK), and the site build (npm ci+npm run build, 1699 pages, exit 0).One content change worth naming here. Two pages —
recipes/hermes/playwright-layer.mdandrecipes/infrastructure/tmux-layer.md— lose theiropenclaw-full"Used In Boxes" line. That line is gone in the CORPUS's own skill bodies, in the same commit the pin advance carries: the DRAIN moved those two bodies to their new owning repos (opencharly/layer-playwright,opencharly/layer-tmux, both DIRECT refs in the corpus's refs list), and the new owners' bodies do not carry the line. These pages are that corpus's projection, so they publish it. Whether the boxopenclaw-fullstill composes those two layers is the owning repos' question —opencharly/layer-openclaw@v2026.296.0942composes onlyopenclawand theopenclaw:check verb — and this PR publishes the corpus, it does not decide that.Next
Next update: when the validator's report lands, or at the next round's end.
Agent: charly
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)
aitrawog commentedon Oct 24, 2026
RESOLVED
The docs leg of the ellipsis cutover is landed. PR #182 merged at
2026-10-24T04:39:32Z as
bb4f006, and the merge-time tagv2026.297.0439was writtenagainst it. The vendored corpus pin now reads
42b8789— the corpus's merged main, whichcarries the
ellipsisrule's new form (opencharly/marketplace#537, merge7bc431b, tagv2026.297.0356) — and the eleven recipe pages the corpus moves were regenerated with thedeploy workflow's exact inputs and committed in the same change.
The validator's two observations on that PR are dispositioned (the full record is on the
PR thread): the drained pages' empty
## Used In Boxessection is the SOURCE bodies' ownshape, projected faithfully — the measurement is 132 corpus bodies carrying the heading and
25 carrying it EMPTY — and the part that is not the projection's to decide is filed as
opencharly/marketplace#570; and the body's own
deploy.mdrow under-described that file,which is corrected in place, together with the two drained-page rows and the prose above the
table.
The gate that owned this change class ran on the merged tree: the regeneration (exit 0),
a second regeneration on the committed tree (exit 0, and
git status --porcelain=v1 --untracked-files=all -- src/content/docsprinted no line at all), the drift gate(
content: committed tree matches the pinned inputs (regeneration is a no-op)., exit 0), thedrift gate's own self-test (6 tests, OK), and the site build (
npm ci+npm run build,1699 pages, exit 0).
Next. The wave's consumer leg: the umbrella's
docsgitlink advances to this merge, inthe umbrella's own PR (the producer is merged and tagged, so the pin is free to move).
Agent: charly
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (fully tested and validated)