434d71b03b
Round 2, Minor. "Workspace seams" carried WORKTREE.SEAM.* and
CONFIG.SEAM.loadConfig-context but nothing for this PR's mechanism or its env
vars, so the one machine-readable place a future author would look said nothing
about the class that has now recurred three times.
Ten predicates across two groups:
CONFIG.LOCATION.SEAM.* — the scrub set's four derivation sources and the rule
that a new var is made ENUMERABLE rather than
appended; the two-families distinction (runtime
configHomes vs GSD's own GSD_HOME/GSD_AGENTS_DIR)
that round 2 turned on; kimi's two config-location
vars; and the in-process scrub requirement, since
HOME sandboxing alone is the trap that produced
Blocker 1 twice.
LIVE-CONFIG.GUARD.SEAM.* — module + exports + why it is scripts/ and not
scripts/lib/; ownership-based scope; the two
non-root targets and their asymmetric treatment;
the truncation contract; the report-not-fatal
severity ratchet; and that CI is structurally blind
here, so green CI is not evidence.
Both generated indexes regenerated. docs/CONTEXT-INDEX.json is checked by
lint:generated-sync (`gen-context-index.cjs --check`) LINE-NUMBER-SENSITIVELY,
and the example's own committed index is separately checked by
lint-example-parser-parity.cjs, which the first regen did not satisfy — editing
CONTEXT.md requires both, and only one of them says so in its error text.
Verified: parity lint rc=0, gen-context-index --check rc=0, full
lint:generated-sync rc=0. Regen diff audited — 10 predicates added, 0 removed,
0 values changed; the example index's remaining churn is line-number re-baking,
which is exactly why the parity lint excludes line numbers.
Dynamic context management — Option-E reference example
Reference example for ADR-1671, "Dynamic context management platform."
This is a non-shipping reference example. It lives outside the build (
src/→bin/lib/), the npm packagefiles[], the installer, and the CI test suite (tests/). Nothing here is compiled into or installed with GSD. The production implementation lands in a later phase of the Dynamic Context Management epic (#1671).
What it demonstrates
The predicate fact-store → JIT selector slice of the platform: parse the
repo-root CONTEXT.md CLASS.subkey=value predicates into structured records,
drift-guard a generated index, and select the relevant predicate subset for a
task — the building block for just-in-time agent-brief assembly instead of
hand-citing a 200 KB file.
Files
context-predicates.cjs— parser + selector + deterministic index builder (self-contained).gen-context-index.cjs—--check/--writedrift-guarded generator +--select.CONTEXT-INDEX.json— sample generated output (415 predicates, 20 classes).demo.cjs— runnable usage example.
Run (from the repo root)
node examples/dynamic-context-management/demo.cjs
node examples/dynamic-context-management/gen-context-index.cjs --select PRED.k320
node examples/dynamic-context-management/gen-context-index.cjs --check
Validation
During research this slice was validated with 42 behavioral tests — predicate
forms, fenced-code / prose skipping, duplicate-id detection, the selector, a
deterministic index, and a fast-check property test. The production
implementation has since landed, with tests/context-predicates.test.cjs and
tests/context-index-sync.test.cjs as its behavioral tests under tests/,
and scripts/lint-example-parser-parity.cjs (wired into npm run lint:ci)
asserting this example and production agree.
Research also surfaced 3 latent duplicate predicate IDs in CONTEXT.md
(RULESET.WORKFLOW_MARKDOWN.FENCES, RULESET.GEMINI.TOOLS.ask_user,
RULESET.GEMINI.TEST_SENTINEL) at the time; all three have since been
resolved and the current index carries 0 duplicate ids.