basics: name the path-filtered-conformance trap as a rule - #594
Merged
Conversation
Two repo settings decide whether a member's baselining can deliver at all, and converging them alongside the sheepdog freshness sweep would be the natural home — a sweep keeps them true where adoption only sets them once. It is blocked on credential scope: FLEET_GITHUB_TOKEN is not an admin token, and both endpoints require admin on the member. Recorded in docs/future-directions.md rather than the sheepdog pack's RULES.md. RULES.md is injected into every session that declares the pack, so it is the wrong place for an idea nobody can act on — a deferred direction should cost no context. The new file is documentation only, and carries no link from any vendored pack file (a pack reaching into the canon's docs/ would dangle in every consumer). Refs #590 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ECifRRammkF9uD7zdEGFpb
auto-merge is a queue for CHECKS, so three CI shapes exist and only one of them silently fails: no pull_request workflow -> baselining merges directly (#588). Coherent. an UNFILTERED sweep -> runs, auto-merge lands on green. Correct. a PATH-FILTERED sweep -> the arm succeeds and no check ever runs. The third is invisible: the repo looks like it has CI, hasPrCi is true, the arm reports success, and the maintenance PR simply never lands. TLDR sat in it — all three of its test workflows filter to the product tree, so a mount-only diff matched nothing, and the same filters had hidden two blocking claudinite-isolation findings on its main. ADVISORY on purpose. Shipping it blocking would red every member lacking the workflow on its very next baselining — which is precisely the #555 failure this rule exists to make less likely. It becomes blocking once the fleet carries the workflow; the promotion is a one-line change. Relevance-first on the vendored mount, so it is inert in any non-member. A repo with no pull_request workflow at all is deliberately not flagged. Refs #592 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ECifRRammkF9uD7zdEGFpb
This was referenced Jul 31, 2026
missingbulb
added a commit
that referenced
this pull request
Jul 31, 2026
Four lessons from the 2026-07-30 window (#594, #591, #583, #586, #578, #581), captured on the home's own local pack. One converts to a check: - `pack-discovery-entry-await` (blocking, `.claudinite/local/packs/claudinite/`) — pack discovery imports every `packs/<name>/pack.mjs` and every `<pack>/skills/<skill>/checks.mjs` on disk *before* activation is consulted, so a module in that graph that is also a CLI entry point is re-imported while still evaluating; a top-level `await` in its entry block then never settles and Node exits 13 having run nothing. That is #581 verbatim, and its fail-soft caller made it silent in every repo. The rule walks the static import graph from the real manifests, judges only the entry block (comments and string bodies blanked first), and stays quiet on the seven CLI workers that legitimately await at top level because none is in that graph. Red-first: with `run()` neutered the two violating fixtures fail and the five guards stay green. Three stay prose in that pack's `RULES.md` — none has a false-positive-free static signature: - green canon CI is not evidence about a consumer (#592's four same-day cases); name the consumer-side evidence in the PR instead. - a pack's `RULES.md` is injected into every declaring session, so an idea nobody can act on belongs in `docs/` — and a pack file may not link there, since `docs/` is outside the vendor set (#591, the #424 class). - pick a scheduled task's cadence from how often its signal actually moves; a `sharedMount` precondition fires nearly every night on a member (#583). `packs/README.md`'s derived corpus tally moves 67 → 68, as `packs-tests/catalog-tally.test.mjs` requires of any rule added anywhere. Full suite `node --test $(git ls-files '*.test.mjs')` → 1029 pass, 0 fail. `check_the_world` → 0 blocking, 9 advisory (all pre-existing `file-placement`). Refs #599 Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
maintenance.delivery: auto-mergearms GitHub's auto-merge, which is a queue for checks. Three CI shapes exist, and only one fails silently:pull_requestworkflow at allThe third is invisible from every angle: the repo looks like it has CI,
hasPrCiis true, the arm reports success, and the maintenance PR simply never lands. TLDR sat in it — all three of its test workflows filter toextension/**,server/**,dev/requirements/**, so a mount-only diff matched nothing. The same filters had also hidden two blockingclaudinite-isolationfindings on itsmainfor as long as they'd existed (fixed in TLDR#156, which adds the workflow).The rule
packs/basics/conformance-workflow.mjs— a member should have a workflow runningcheck_the_worldon every pull request, unfiltered.Advisory, deliberately. Shipping it blocking would turn every member lacking the workflow red on its very next baselining — which is exactly the #555 failure mode this rule exists to make less likely: a required thing added to the canon with no path for consumers to comply first. It becomes blocking once the fleet carries the workflow, and the promotion is a one-line change with the reasoning recorded in the file.
Relevance-first on the vendored mount, so it is inert in any non-member. A repo with no
pull_requestworkflow is deliberately not flagged — that is #588's coherent shape, not a defect.Verification
Full CI test set 1029 pass / 0 fail;
check_the_world0 blocking, 9 advisory (all pre-existingfile-placement). Ten see-it-fail cases, including the exact TLDR shape, and verified firing against the real TLDR tree before the fix and silent after it.packs/README.mdcorpus tally updated 66 → 67 in the same change, as its guard requires.Refs #592
Generated by Claude Code