CORPUS_SENTINEL (crates/intent/src/lib.rs:14) is "context/vrs". This repository's corpus is
intent/, so the constant is wrong here — at two sites, not one. Both were raised as review
threads on #6.
Site 1 — the decision directory is silently skipped
meta_vrs_decision_dir (lib.rs:1249) tries <root>/.decisions, then
<root>/context/vrs/.decisions. Aimed at this repo's root, neither exists, so the decision-shape pass
does not run and says nothing.
Proven by execution at 18299fe0e, one planted malformed decision:
| invocation |
VRS.ENF.meta-decision-shape |
intent check . |
0 |
intent check intent |
4 |
Not a false green — the repo-root run exits 1 on 8 unrelated diagnostics. The failure is a missing
rule inside a failing run, which is harder to notice than a green that should have been red.
Site 2 — repository-root discovery, and nothing tracked this before
review_workspace (lib.rs:1677) walks ancestors for .git or the sentinel, using "this
directory contains the corpus" as evidence of where the repository begins. In this repo the second
probe never matches. With no .git — an exported tree, a build sandbox, CAIC — the walk falls through
and returns the corpus itself, so the reviewer is handed <repo>/intent as its workspace and the
surrounding implementation is excluded.
Derived by reading, not measured. This repo has a .git, so the walk finds it first and the site
does not bite today. Recording that distinction rather than implying both were executed.
Why the two sites are not the same fix
They want different facts from one constant. Site 1 needs where the corpus is. Site 2 needs how
far above the corpus the repository begins — context/vrs sits two levels below its root, intent/
sits one. That distance is what the constant actually encodes.
Agreed fix: converge the layouts, keep one hardcoded path
Rather than a declaration format, a known-layouts list, or caller-supplied roots, the corpora
themselves converge as part of the comprehensive VRS → Intent rename:
this repo intent/ -> context/intent/
consumer context/vrs/ -> context/intent/
const CORPUS: &str = "context/intent";
Both sites then resolve correctly from one string, and site 2's problem disappears rather than being
solved: with both corpora at the same depth, there is no distance left to encode. No new abstraction
is introduced.
Consistent with 0022, which designates exactly one corpus and defers discovery-by-walking — a fixed
path is a designation, and context/cli/.decisions/ stays outside strict enforcement as 0022
intends.
Carried by the rename, not by a bespoke patch
The rename has to touch this constant regardless, so fixing it separately first would be work the
sweep then redoes. Known costs: context/cli/* links into the corpus as ../../intent/ and become
../intent/; CI's intent check intent becomes intent check context/intent.
Posted on behalf of @schickling
| field |
value |
agent_name |
unknown |
agent_tool |
Claude Code |
agent_tool_version |
2.1.220 |
agent_runtime |
Claude Code 2.1.220 |
agent_session_lookup |
unavailable |
tooling_profile |
dotfiles@unknown-dirty |
CORPUS_SENTINEL(crates/intent/src/lib.rs:14) is"context/vrs". This repository's corpus isintent/, so the constant is wrong here — at two sites, not one. Both were raised as reviewthreads on #6.
Site 1 — the decision directory is silently skipped
meta_vrs_decision_dir(lib.rs:1249) tries<root>/.decisions, then<root>/context/vrs/.decisions. Aimed at this repo's root, neither exists, so the decision-shape passdoes not run and says nothing.
Proven by execution at
18299fe0e, one planted malformed decision:VRS.ENF.meta-decision-shapeintent check .intent check intentNot a false green — the repo-root run exits 1 on 8 unrelated diagnostics. The failure is a missing
rule inside a failing run, which is harder to notice than a green that should have been red.
Site 2 — repository-root discovery, and nothing tracked this before
review_workspace(lib.rs:1677) walks ancestors for.gitor the sentinel, using "thisdirectory contains the corpus" as evidence of where the repository begins. In this repo the second
probe never matches. With no
.git— an exported tree, a build sandbox, CAIC — the walk falls throughand returns the corpus itself, so the reviewer is handed
<repo>/intentas its workspace and thesurrounding implementation is excluded.
Derived by reading, not measured. This repo has a
.git, so the walk finds it first and the sitedoes not bite today. Recording that distinction rather than implying both were executed.
Why the two sites are not the same fix
They want different facts from one constant. Site 1 needs where the corpus is. Site 2 needs how
far above the corpus the repository begins —
context/vrssits two levels below its root,intent/sits one. That distance is what the constant actually encodes.
Agreed fix: converge the layouts, keep one hardcoded path
Rather than a declaration format, a known-layouts list, or caller-supplied roots, the corpora
themselves converge as part of the comprehensive VRS → Intent rename:
Both sites then resolve correctly from one string, and site 2's problem disappears rather than being
solved: with both corpora at the same depth, there is no distance left to encode. No new abstraction
is introduced.
Consistent with
0022, which designates exactly one corpus and defers discovery-by-walking — a fixedpath is a designation, and
context/cli/.decisions/stays outside strict enforcement as0022intends.
Carried by the rename, not by a bespoke patch
The rename has to touch this constant regardless, so fixing it separately first would be work the
sweep then redoes. Known costs:
context/cli/*links into the corpus as../../intent/and become../intent/; CI'sintent check intentbecomesintent check context/intent.Posted on behalf of @schickling
agent_nameagent_toolagent_tool_versionagent_runtimeagent_session_lookuptooling_profile