* test(#1168): make phase-6 gate un-gameable — reject empty stubs + require loop shrink The migration assertion previously checked only role==feature, so a registration-only stub (empty hooks, logic left inline) would turn the gate green while phase 6 stayed incomplete — the exact false-completion pattern this gate exists to prevent. Strengthen it: each ADR-named feature must OWN its behavior (>=1 hook, or a command family); and plan-phase.md/execute-phase.md must shrink strictly below their frozen pre-phase-6 sizes (94519/93166 LF bytes), which also defeats double-run gaming (declare a hook but keep the inline block -> file does not shrink -> red). Gate now 5 pass / 4 fail (orphaned execute:wave:post, empty/unregistered features, config-key leaks, no shrink). Green is now reachable only by REAL migration. Refs #1168, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): migrate gap-analysis to a Capability (plan:post gate) First real ADR-857 phase-6 migration (pattern-defining tracer). gap-analysis moves from an inline post_planning_gaps branch in plan-phase.md to a real plan:post gate Capability: - capabilities/gap-analysis/capability.json: role:feature, plan:post gate (when=workflow.post_planning_gaps, blocking:false advisory), OWNS workflow.post_planning_gaps (federated out of central schema). - plan-phase.md: inline config-get + gsd_run gap-analysis block replaced with a plan:post render-hooks call site dispatching the gate; file shrinks 94519->93279. - src/check-command-router.cts: cmdGapAnalysisPlanPost runs the real gap analysis via gap-checker. - post_planning_gaps removed from central manifest; resolves via federated config (default true preserved). - tests/post-planning-gaps-2493: re-pointed to assert capability ownership. Verified: gate 5 pass / 4 fail (gap-analysis cleared from migration, plan:post-orphan, config-leak, and plan-phase shrink checks); loadConfig still returns post_planning_gaps=true; check command runs real analysis; 392/392 in the config/registry/federation/router net. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): migrate profile-pipeline to a command-family Capability ADR-857 Decision 7: profile-pipeline becomes a command-family Capability (like audit/intel/graphify). capabilities/profile-pipeline/capability.json declares an 8-command family (scan-sessions, extract-messages, profile-sample, write-profile, profile-questionnaire, generate-dev-preferences, generate-claude-profile, generate-claude-md) backed by a new gsd-core/bin/lib/profile-pipeline-command-router.cjs; the inline case arms are removed from gsd-tools.cjs. Owns profile-pipeline.enabled (federated). Verified: registry shows role:feature with commands.length=8; scan-sessions/profile-sample run live via the family; gate cleared profile-pipeline from the empty-stub failure (only tdd/schema-gate/drift remain); 296/296 registry+inventory+gsd-tools tests; lint 0 errors. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1167): wire execute:wave:post + implement ui.safety-gate check Revives the second dead gate from #1167: ui.gates@execute:wave:post was declared but never dispatched AND its check.query (ui.safety-gate) was unimplemented. Adds the per-wave execute:wave:post render-hooks call site in execute-phase.md (fires after each wave's merge/cleanup, before the next forks) and implements cmdUiSafetyGate (frontend + UI-SPEC aware, mirrors cmdUiPlanGate) in check-command-router. +17 regression tests. Verified: phase-6 orphaned-points conformance test now PASSES (gate 6 pass / 3 fail); ui-safety-gate routable in dot+hyphen forms; check-ui-safety-gate 17/17, check-ui-plan-gate 18/18; lint 0 errors. Refs #1167, #1168. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): migrate drift (schema + codebase) to execute:wave:post gates Removes the inline schema_drift_gate + codebase_drift_gate steps (77 lines) from execute-phase.md; drift becomes a Capability with two execute:wave:post gates (verify.schema-drift blocking, verify.codebase-drift advisory) dispatched via the per-wave render-hooks call site. check-command-router routes verify.schema-drift / verify.codebase-drift to the real detectors. Federates workflow.drift_threshold / drift_action / schema_drift_gate out of central. Also fixes the execute:wave:post dispatch prose to run NON-blocking (advisory) gates too — the prior version only ran blocking gates, which would have silently dropped the codebase-drift advisory after its inline step was removed. Behavior preserved. Verified: gate 7 pass / 2 fail (drift cleared from stub + config-leak; execute-phase.md 92297 < 93166 frozen -> shrink passes); both drift checks run real detection; loadConfig defaults preserved (threshold=3, action=warn, gate=true); drift-detection 56/56 + schema-drift 34/34; lint 0 errors. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): migrate tdd to a Capability (plan:pre contribution + execute:post gate) tdd becomes a real Capability: a plan:pre contribution injects the <tdd_mode_active> planner guidance (rendered from PLAN_PRE_HOOKS_JSON like security's contribution), and an execute:post gate (tdd.review-checkpoint, advisory) runs the real end-of-phase RED/GREEN review via a new check-command handler. Inline tdd_mode reads + the inline planner block + the tdd_review_checkpoint step are removed; workflow.tdd_mode is federated out of central. The MVP+TDD per-task RED-commit gate is preserved — TDD_MODE is now derived from the execute:post hooks (capId==tdd active), not an inline config-get. BEHAVIOR CHANGE (documented, not silent): the --tdd CLI flag now persists workflow.tdd_mode=true via config-set instead of being per-invocation. Rationale: tdd is now a config-toggled Capability, and env vars do not persist across the workflow's separate bash blocks (config does), so an ephemeral override isn't cleanly achievable; --tdd therefore enables the tdd capability, consistent with how all capabilities are toggled. Verified: gate 7 pass / 2 fail (tdd cleared from stub + config-leak; plan-phase + execute-phase both < frozen sizes); contribution injection + execute:post gate dispatch wired; MVP+TDD gate preserved; tdd.review-checkpoint runs real review; full unit suite 556/0; lint 0 errors. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): migrate schema-gate to a plan:pre contribution Capability The plan-time schema-push detection (former plan-phase.md §5.7) becomes a schema-gate Capability: a plan:pre contribution (into:planner, when:workflow.schema_push_detection) whose fragment carries the full ORM-detection + [BLOCKING] schema-push-task injection logic, rendered into the planner via the existing plan:pre render-hooks dispatch. The inline §5.7 block is removed (plan-phase.md 94519->90445). workflow.schema_push_detection is a new capability-owned (federated) key, default true. (The execute-side schema-drift gate was migrated separately into the drift capability.) Verified: registry inlines the fragment (len 2704) so it is actually delivered at plan:pre; gate 8 pass / 1 fail — all 5 ADR-named features now real Capabilities, only the config-leak test remains (intel/security, next unit). Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(#1169): close the 3 capability config-key leaks — phase-6 gate now GREEN Removes the last inline config-get reads of capability-owned keys from plan-phase.md. security_asvs_level/security_block_on now flow through the security plan:pre contribution via a new loop-resolver configValues mechanism (resolves declared config keys with the same 4-level precedence as activation and attaches them to the rendered hook); the §5.55 banner reads them from PLAN_PRE_HOOKS_JSON. intel.enabled becomes a real intel plan:pre step (ref.command: intel api-surface) dispatched via render-hooks; the inline intel branch is gone. gen-capability-registry now validates ref.command as a third dispatch shape. Verified: phase-6 capstone conformance gate is FULLY GREEN (9/0); 3 leaks gone (grep=0); security configValues resolve to {2,medium}/default {1,high}; intel step present only when enabled; loop-render-hooks 62/0, capability-registry 287/0, capability-state/federated-config 113/0; lint 0 errors. Closes the migration half of #1169. Refs #1139, #1167, #1168. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): address adversarial review — restore schema-drift block, generic planner injection, uniform gate contract Adversarial review caught 2 real regressions the green gate missed: (1) schema-drift no longer blocked — the execute:wave:post dispatch read GATE_RESULT.block but verify.schema-drift emitted drift_detected/blocking, and onError:skip wrongly bypassed positive blocks; (2) only tdd's plan:pre contribution was injected into the planner, dropping schema-gate's schema-push detection and security's threat-model guidance. Fixes: (A) every gate check returns a uniform boolean 'block' under --raw (the dispatch form), with advisory gates (tdd/gap) carrying their report in 'message'; (B) gate-dispatch contract corrected at all sites — onError governs command errors only, a blocking gate's positive block always halts; (C) generic planner injection of all plan:pre contributions where into=='planner' (tdd + schema-gate + security incl configValues); (D) two new conformance assertions: planner contributions injected generically + every gate check.query returns boolean block under --raw. Verified: gate 11/11; all 6 gate checks return boolean block under --raw; full suite 595/0; lint 0 errors. Refs #1167, #1168, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): restore MVP+TDD end-of-phase blocking escalation (2nd adversarial pass) The migrated tdd execute:post gate is statically blocking:false, but the contract (references/execute-mvp-tdd.md + CONTEXT.md) requires the end-of-phase TDD review to ESCALATE from advisory to blocking when MVP_MODE && TDD_MODE && a TDD plan misses a RED/GREEN commit. The migration prose had downgraded this to a 'strong advisory recommendation' — silent loss of the blocking escalation. Restore it: the tdd-gate dispatch now refuses to mark the phase complete (Phase blocked message) under MVP+TDD when GATE_RESULT.block is true; advisory otherwise. Also strengthen tests/execute-mvp-tdd-gate.test.cjs: hasBlockingEscalation previously matched any line with 'blocking'+'mvp+tdd' (so 'advisory (blocking: false) ... under MVP+TDD' was a false green); now it requires the real refusal semantics ('refuse to mark the phase complete' / 'phase blocked'). Caught by 2nd adversarial review pass. Verified: execute-phase.md 92702 < 93166 frozen; mvp-tdd-gate + phase-6 gate 19/0; full suite green; lint 0 errors. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): restore MVP+TDD proceed-block, codebase auto-remap, schema skip-flag (3rd adversarial pass) 3rd adversarial pass found 4 more silent regressions: (1) the tdd MVP+TDD 'refuse to mark complete' was nullified by a downstream 'ALWAYS proceed regardless of gate results' line — proceed is now conditional (stops on an active MVP+TDD block); (2) the test now asserts the proceed is NOT an unconditional override; (3) codebase-drift auto-remap (spawn gsd-codebase-mapper when drift_action=auto-remap) was dropped — the execute:wave:post advisory dispatch now consumes spawn_mapper/directive; (4) GSD_SKIP_SCHEMA_CHECK bypass was lost from the gate path — cmdVerifySchemaDrift now honors the env var (block:false when set). Verified: no unconditional proceed; GSD_SKIP_SCHEMA_CHECK=true -> block:false; gate 11/11 + mvp-tdd 9/9; full suite 569/0; lint 0; execute-phase.md 93109 < 93166. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): init.cts reads federated config keys from nested path (4th adversarial pass) Config federation moved tdd_mode/research/nyquist_validation from flat config.<key> to nested config.workflow.<key>, but src/init.cts still read them flat — so init.plan-phase/init.execute-phase emitted tdd_mode:false / research_enabled:undefined / nyquist:undefined regardless of config (a public command-contract regression; the migrated loops use render-hooks so enforcement was unaffected). Read via config.workflow (type-safe Record cast). Now init reflects the same resolved values + federated defaults (research/nyquist default true) as the render-hooks path. Verified: build clean; init.plan-phase emits tdd_mode:true/research:false/nyquist:false for set config, defaults true for empty; full suite 591/0; lint 0. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(#1169): add changeset for ADR-857 phase-6 completion (PR #1183) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): complete phase-6 migration fallout — restore TEXT_MODE, fix registry .claude leak, re-point stale workflow-contract tests The capability migration left real regressions and stale consumer tests that the per-module unit suite missed but the full cross-platform suite caught (27 failing tests): Real source regressions (fixed): - execute-phase.md lost its AskUserQuestion TEXT_MODE plain-text fallback when the inline schema_drift_gate step was removed — non-Claude runtimes would stall. Restored, and the execute:post gate-dispatch prose de-duplicated to cite the execute:wave:post contract (loop body shrinks below the frozen pre-phase-6 ceiling while keeping every onError/blocking nuance). - capabilities/tdd inline fragment hardcoded `@~/.claude/gsd-core/references/tdd.md`, baked verbatim into the committed capability-registry.cjs and leaked the install path on 11 non-Claude runtimes (registry .cjs is copied, not path-converted). Made the fragment path-free; regenerated the registry. The phase-6 conformance gate now guards this (no ~/.claude install path in any capability source or the generated registry). - plan-phase.md: removed a §5.7 stub re-added in error and routed Branch 2 to step 6 (schema-gate is a plan:pre capability, §5.7 is gone). Stale workflow-contract tests re-pointed to the capability dispatch they now must assert (behavior verified preserved in source first, assertions kept equal-or-stronger): bug-621 + bug-2851 (gap-analysis via gsd_run render-hooks plan:post + registry binding), feat-2527 (tdd_mode federated out of central), phase6-planning + plan-phase-ui-redirect (§5.6 bounded by ## 6.), plan-phase-drift-guard (intel when:intel.enabled skip branch). profile-pipeline-command-router.cjs un-ignored from eslint (hand-written, no TS source) + stale disable comments removed. Size baseline regenerated. Verified: full suite 15140 tests / 0 fail; lint 0 errors; conformance gate green legitimately. Refs #1139, #1167, #1168, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(#1169): add ADR-857 E2E content-test coverage for the 12 loop points + capability deliverables Grounds the capability engine in behavioral E2E tests (drive the real render-hooks/check CLI + the real registry, assert typed result content — no source-grep), structured around what ADR-857 says to deliver. 207 tests; each genuineness-checked (flip the expectation, confirm it fails). Per-loop-point dispatch (7 files): empty-point negative-space across the 6 no-hook points; verify:post 3-step resolution+ordering+onError; plan:pre contribution/configValues + ui.plan-gate + intel; plan:post gap-analysis; execute:wave:post drift+ui gates via the check route (schema-drift block/skip, codebase-drift threshold BVA, auto-remap); execute:post tdd.review-checkpoint RED/GREEN; ship:pre security gate resolution + frontmatter-get predicate pieces. ADR-deliverable coverage (4 files): predicate boundary held (edge/prohibition probes stay core, not off-by-default Feature Capabilities — phase-6 exception); core loop runs with zero capabilities (all 12 points empty, init bundles resolve); contribution merge (multiple ordered <contribution from=> blocks); federated-config key removal on uninstall. federated-config allowlisted for its 3-file split (unit + integration + lifecycle). Refs #1139, #1167, #1168, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): remove dead drifted converter dups + address adversarial review Lint cleanup (root-caused, not waved off): src/runtime-artifact-conversion.cts carried 11 agent-converter functions (+5 orphaned consts/helpers) that were never exported, never called, and had silently DRIFTED from the live hand-authored copies in bin/install.js (one even referenced an undefined `claudeToCopilotTools`). Deleted the dead duplicates; install.js's live copies are untouched (it never imported these). Lint now 0 errors / 0 warnings. Adversarial-review (Codex) findings fixed: - HIGH: execute-phase.md TDD_MODE used `jq ... || echo false`, silently disabling the MVP+TDD blocking gate on jq-less runtimes. Reverted to the `node -e` form (node is guaranteed; matches the file's other node-e usages) so a missing optional tool can no longer fail-open a blocking safety path. - MEDIUM: federated-config-key-removal orphan-key test was vacuous (it skipped the orphan assertion). Now asserts the removed capability's key is genuinely not surfaced/validated after uninstall. - LOW: phase-6 conformance leak regex broadened to catch absolute-home and Windows-backslash `.claude/(gsd-core|commands|agents|hooks)` paths, not only `~`/`$HOME` forward-slash forms. - LOW: bug-2851 plan:post dispatch assertion now requires `--raw` (matched its stated contract). - nit: plan-pre intel-step test duplicate assertion replaced with a distinct structured-output check. Size baseline regenerated (execute-phase.md 93089 < 93166 frozen). Refs #1167, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(#1169): make runtime-homes-descriptor-drive titles environment-independent The descriptor-equivalence test embedded the absolute golden config path (`os.homedir()`-derived) directly in each `test(...)` title, so titles differed between macOS (`/Users/x/.claude`) and Docker (`/home/gsdtest/.claude`). Every test PASSES on both platforms (15885/0 leaf tests each), but gsd-test-summary compares results by title and reported 29+29 false "only in Mac / only in Docker" discrepancies for tests that actually pass everywhere. Move the golden path out of the title and into the assertion message (still shown on failure); titles are now byte-identical across platforms so the cross-platform comparator matches them. No assertion logic or golden values changed. Refs #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#1169): derive TDD_MODE via gsd_run --active-cap, not node -e (fix prompt-injection CI gate) The prior fix reverted execute-phase.md:181 from jq to `node -e` to close a Codex HIGH (jq||echo-false silently disabling the MVP+TDD blocking gate on jq-less runtimes) — but the CI prompt-injection scanner BLOCKS new `node -e` in workflow markdown (inline code-exec = injection vector), turning the security gate red. Both forms were wrong: node -e fails the scanner; jq fail-opens a blocking safety gate; `config-get workflow.tdd_mode` is forbidden by the conformance leak gate (tdd_mode is capability-owned). Correct fix (what Codex recommended): a gsd_run-native boolean. Add an `--active-cap <capId>` flag to `loop render-hooks <point>` that resolves hooks the normal way and prints exactly `true`/`false` for whether a capId is active — scanner-safe (canonical launcher, no inline code), node-reliable (no optional jq to fail-open), and leak-free (render-hooks resolution, not config-get). execute-phase.md:181 now `TDD_MODE=$(gsd_run loop render-hooks execute:post --active-cap tdd)`. +5 behavioral tests for the flag. Verified: prompt-injection-scan --diff origin/next → 0 findings; conformance gate 13/13 (execute-phase.md 92934 < 93166); execute-mvp-tdd + tdd-mode + loop-render-hooks 87/0; lint 0/0. Refs #1167, #1169. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
419 lines
14 KiB
JavaScript
419 lines
14 KiB
JavaScript
'use strict';
|
|
|
|
/**
|
|
* federated-config-key-removal.test.cjs
|
|
*
|
|
* ADR-857 deliverable F — Decision 3:
|
|
* "Uninstalling a Capability removes its config keys cleanly."
|
|
*
|
|
* Tests:
|
|
* [happy] Capability X present → its key surfaces; X removed → key gone, others intact.
|
|
* [happy] loadConfig after removing a capability no longer surfaces the key, but central
|
|
* base-config keys remain.
|
|
* [BVA] Orphaned user value for the removed key is dropped — not leaked as a phantom key.
|
|
* [negative] Removing capability 'x' does NOT drop a differently-prefixed capability's key
|
|
* (e.g. 'xy.enabled' survives when only 'x.enabled' is removed).
|
|
*/
|
|
|
|
const { describe, test, beforeEach, afterEach } = require('node:test');
|
|
const assert = require('node:assert/strict');
|
|
const fs = require('node:fs');
|
|
const path = require('node:path');
|
|
const os = require('node:os');
|
|
|
|
const { cleanup } = require('./helpers.cjs');
|
|
|
|
const { mergeFederatedConfig } = require('../gsd-core/bin/lib/federated-config.cjs');
|
|
|
|
const configLoader = require('../gsd-core/bin/lib/config-loader.cjs');
|
|
const {
|
|
loadConfig,
|
|
_setFederatedRegistryForTests,
|
|
_resetFederatedRegistryForTests,
|
|
} = configLoader;
|
|
|
|
// ─── Fixtures ─────────────────────────────────────────────────────────────────
|
|
|
|
/** Never treated as a central key — all keys federated freely. */
|
|
const neverCentral = (_key) => false;
|
|
|
|
/** Minimal well-formed boolean slice. */
|
|
function boolSlice(owner, defaultValue = true) {
|
|
return { owner, type: 'boolean', default: defaultValue, description: `Boolean key for ${owner}.` };
|
|
}
|
|
|
|
// ─── Temp project helpers (mirrors federated-config-loadconfig.test.cjs) ──────
|
|
|
|
let tmpDirs = [];
|
|
|
|
beforeEach(() => {
|
|
tmpDirs = [];
|
|
_resetFederatedRegistryForTests();
|
|
});
|
|
|
|
afterEach(() => {
|
|
_resetFederatedRegistryForTests();
|
|
for (const d of tmpDirs) {
|
|
cleanup(d);
|
|
}
|
|
});
|
|
|
|
function mkTempProject() {
|
|
const d = fs.mkdtempSync(path.join(os.tmpdir(), 'gsd-cap-removal-test-'));
|
|
tmpDirs.push(d);
|
|
fs.mkdirSync(path.join(d, '.planning', 'phases'), { recursive: true });
|
|
return d;
|
|
}
|
|
|
|
function writeConfig(dir, obj) {
|
|
fs.writeFileSync(
|
|
path.join(dir, '.planning', 'config.json'),
|
|
JSON.stringify(obj, null, 2),
|
|
'utf-8',
|
|
);
|
|
}
|
|
|
|
// ─── 1. [happy] key present → surfaces; capability removed → key gone ─────────
|
|
|
|
describe('[happy] capability X present then removed — key lifecycle', () => {
|
|
test('registry WITH capability X: x.enabled surfaces with default true', () => {
|
|
const withX = {
|
|
'x.enabled': boolSlice('cap-x', true),
|
|
};
|
|
|
|
const result = mergeFederatedConfig({
|
|
configSchema: withX,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
// Positive assertion: the key is in validKeys AND values
|
|
assert.ok(
|
|
result.validKeys.includes('x.enabled'),
|
|
'x.enabled must be in validKeys when cap-x is installed',
|
|
);
|
|
assert.strictEqual(
|
|
result.values['x.enabled'],
|
|
true,
|
|
'x.enabled default must be true',
|
|
);
|
|
assert.deepEqual(result.warnings, [], 'no warnings for valid federated key');
|
|
});
|
|
|
|
test('registry WITHOUT capability X: x.enabled is absent from result', () => {
|
|
// Registry after cap-x is uninstalled — its key is no longer in configSchema
|
|
const withoutX = {};
|
|
|
|
const result = mergeFederatedConfig({
|
|
configSchema: withoutX,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
assert.ok(
|
|
!result.validKeys.includes('x.enabled'),
|
|
'x.enabled must NOT be in validKeys after cap-x is removed',
|
|
);
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(result.values, 'x.enabled'),
|
|
'x.enabled must NOT appear in values after cap-x is removed',
|
|
);
|
|
assert.strictEqual(Object.keys(result.values).length, 0, 'values must be empty');
|
|
});
|
|
|
|
test('[no contamination] removing cap-x leaves cap-y.flag intact', () => {
|
|
// Before removal: both capabilities present
|
|
const withBoth = {
|
|
'x.enabled': boolSlice('cap-x', true),
|
|
'y.flag': boolSlice('cap-y', false),
|
|
};
|
|
|
|
const before = mergeFederatedConfig({
|
|
configSchema: withBoth,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
assert.ok(before.validKeys.includes('x.enabled'), 'x.enabled present before removal');
|
|
assert.ok(before.validKeys.includes('y.flag'), 'y.flag present before removal');
|
|
|
|
// After removal: only cap-y remains in the registry
|
|
const withoutX = {
|
|
'y.flag': boolSlice('cap-y', false),
|
|
};
|
|
|
|
const after = mergeFederatedConfig({
|
|
configSchema: withoutX,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
// x.enabled must be gone
|
|
assert.ok(
|
|
!after.validKeys.includes('x.enabled'),
|
|
'x.enabled must be absent after cap-x removal',
|
|
);
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(after.values, 'x.enabled'),
|
|
'x.enabled must not appear in values after removal',
|
|
);
|
|
|
|
// y.flag must still be present AND have the correct value
|
|
assert.ok(
|
|
after.validKeys.includes('y.flag'),
|
|
'y.flag must still be in validKeys after cap-x removal',
|
|
);
|
|
assert.strictEqual(
|
|
after.values['y.flag'],
|
|
false,
|
|
'y.flag value must remain false (its default) after cap-x removal',
|
|
);
|
|
});
|
|
});
|
|
|
|
// ─── 2. [happy] loadConfig: removed capability key absent, base keys intact ───
|
|
|
|
describe('[happy] loadConfig after capability removal — base keys survive', () => {
|
|
test('cap-x present → loadConfig surfaces mytool.enabled; cap-x absent → key gone', () => {
|
|
const tmpDir = mkTempProject();
|
|
writeConfig(tmpDir, {});
|
|
|
|
// Phase A: cap-x installed
|
|
_setFederatedRegistryForTests({
|
|
configSchema: {
|
|
'mytool.enabled': boolSlice('cap-x', true),
|
|
},
|
|
});
|
|
|
|
const resultWith = loadConfig(tmpDir);
|
|
assert.ok(
|
|
typeof resultWith['mytool'] === 'object' && resultWith['mytool'] !== null,
|
|
'mytool section must exist when cap-x is installed',
|
|
);
|
|
assert.strictEqual(
|
|
resultWith['mytool']['enabled'],
|
|
true,
|
|
'mytool.enabled must be true (cap-x default)',
|
|
);
|
|
|
|
// Phase B: cap-x uninstalled — registry now empty
|
|
_resetFederatedRegistryForTests();
|
|
_setFederatedRegistryForTests({ configSchema: {} });
|
|
|
|
const resultWithout = loadConfig(tmpDir);
|
|
// Central base-config key must still be present
|
|
assert.ok(
|
|
Object.prototype.hasOwnProperty.call(resultWithout, 'model_profile'),
|
|
'model_profile (central key) must still exist after cap-x removal',
|
|
);
|
|
// Federated key must be absent — either undefined or not surfaced under 'mytool'
|
|
const myToolSection = resultWithout['mytool'];
|
|
const enabledValue = (myToolSection && typeof myToolSection === 'object')
|
|
? myToolSection['enabled']
|
|
: undefined;
|
|
assert.strictEqual(
|
|
enabledValue,
|
|
undefined,
|
|
'mytool.enabled must NOT be present after cap-x removal; got: ' + JSON.stringify(enabledValue),
|
|
);
|
|
});
|
|
|
|
test('base config keys (model_profile, research) survive capability removal', () => {
|
|
const tmpDir = mkTempProject();
|
|
writeConfig(tmpDir, { model_profile: 'fast', research: false });
|
|
|
|
// Install and then remove a synthetic capability
|
|
_setFederatedRegistryForTests({
|
|
configSchema: {
|
|
'extra.flag': boolSlice('cap-extra', true),
|
|
},
|
|
});
|
|
const before = loadConfig(tmpDir);
|
|
assert.strictEqual(before['model_profile'], 'fast', 'model_profile from user config before removal');
|
|
assert.strictEqual(before['research'], false, 'research from user config before removal');
|
|
|
|
_setFederatedRegistryForTests({ configSchema: {} });
|
|
const after = loadConfig(tmpDir);
|
|
|
|
// Central keys from user's config.json must be unchanged
|
|
assert.strictEqual(after['model_profile'], 'fast', 'model_profile must survive capability removal');
|
|
assert.strictEqual(after['research'], false, 'research must survive capability removal');
|
|
});
|
|
});
|
|
|
|
// ─── 3. [BVA] orphaned user value not surfaced after removal ──────────────────
|
|
|
|
describe('[BVA] orphaned user value is silently dropped after capability removal', () => {
|
|
test('user config sets removed key → orphaned value not surfaced as phantom', () => {
|
|
// User has 'mytool.enabled': false in their config.json
|
|
// BUT the capability is now uninstalled (not in registry configSchema)
|
|
const result = mergeFederatedConfig({
|
|
configSchema: {}, // cap-x removed — configSchema is empty
|
|
isCentralKey: neverCentral,
|
|
userConfig: { mytool: { enabled: false } }, // user value remains in file
|
|
});
|
|
|
|
// The orphaned user value must NOT leak into validKeys or values
|
|
assert.ok(
|
|
!result.validKeys.includes('mytool.enabled'),
|
|
'orphaned user key must not appear in validKeys',
|
|
);
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(result.values, 'mytool.enabled'),
|
|
'orphaned user key must not appear in values',
|
|
);
|
|
// The entire values map must be empty (no phantom keys)
|
|
assert.strictEqual(
|
|
Object.keys(result.values).length,
|
|
0,
|
|
'values must be empty when registry has no keys — got: ' + JSON.stringify(Object.keys(result.values)),
|
|
);
|
|
assert.deepEqual(result.validKeys, [], 'validKeys must be empty when registry has no keys');
|
|
});
|
|
|
|
test('user config sets removed key — top-level orphan also not surfaced', () => {
|
|
// Top-level orphan: user set 'orphan_flag' but the cap is gone
|
|
const result = mergeFederatedConfig({
|
|
configSchema: {},
|
|
isCentralKey: neverCentral,
|
|
userConfig: { orphan_flag: true },
|
|
});
|
|
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(result.values, 'orphan_flag'),
|
|
'top-level orphaned key must not appear in values',
|
|
);
|
|
assert.deepEqual(result.validKeys, []);
|
|
assert.strictEqual(Object.keys(result.values).length, 0);
|
|
});
|
|
|
|
test('loadConfig: orphaned user value in config.json not surfaced after removal', () => {
|
|
const tmpDir = mkTempProject();
|
|
// User config contains a value for a key whose capability will be removed
|
|
writeConfig(tmpDir, { orphancap: { flag: true } });
|
|
|
|
// Capability removed: inject empty registry
|
|
_setFederatedRegistryForTests({ configSchema: {} });
|
|
|
|
const result = loadConfig(tmpDir);
|
|
|
|
// The orphaned capability key must NOT be surfaced in the resolved config object.
|
|
// loadConfig extracts only known/central/federated keys into _baseConfig — any key
|
|
// whose capability has been uninstalled (configSchema: {}) must not appear in the result.
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(result, 'orphancap'),
|
|
'orphaned top-level key must not appear in resolved config when capability is removed',
|
|
);
|
|
// Central keys must remain unaffected by capability removal.
|
|
assert.ok(
|
|
Object.prototype.hasOwnProperty.call(result, 'model_profile'),
|
|
'model_profile must still be present (central key unaffected by federated removal)',
|
|
);
|
|
});
|
|
});
|
|
|
|
// ─── 4. [negative] removing 'x' does NOT drop 'xy.enabled' ──────────────────
|
|
|
|
describe('[negative] prefix-adjacent key not dropped when shorter-prefix cap removed', () => {
|
|
test("removing cap 'x' (key x.enabled) does NOT remove cap 'xy' (key xy.enabled)", () => {
|
|
// Registry after 'x' is uninstalled but 'xy' remains
|
|
const registryAfterXRemoved = {
|
|
'xy.enabled': boolSlice('cap-xy', false),
|
|
};
|
|
|
|
const result = mergeFederatedConfig({
|
|
configSchema: registryAfterXRemoved,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
// x.enabled must not appear (was removed)
|
|
assert.ok(
|
|
!result.validKeys.includes('x.enabled'),
|
|
'x.enabled must not appear (cap-x was uninstalled)',
|
|
);
|
|
assert.ok(
|
|
!Object.prototype.hasOwnProperty.call(result.values, 'x.enabled'),
|
|
'x.enabled must not be in values',
|
|
);
|
|
|
|
// xy.enabled MUST still appear (different capability)
|
|
assert.ok(
|
|
result.validKeys.includes('xy.enabled'),
|
|
'xy.enabled must still be present after cap-x removal',
|
|
);
|
|
assert.strictEqual(
|
|
result.values['xy.enabled'],
|
|
false,
|
|
'xy.enabled value must be false (cap-xy default), not contaminated by cap-x removal',
|
|
);
|
|
});
|
|
|
|
test("removing 'x' does not drop 'x2.enabled' (numeric suffix, distinct cap)", () => {
|
|
const registryAfterXRemoved = {
|
|
'x2.enabled': boolSlice('cap-x2', true),
|
|
};
|
|
|
|
const result = mergeFederatedConfig({
|
|
configSchema: registryAfterXRemoved,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
assert.ok(
|
|
!result.validKeys.includes('x.enabled'),
|
|
'x.enabled must not appear (not in registry)',
|
|
);
|
|
assert.ok(
|
|
result.validKeys.includes('x2.enabled'),
|
|
'x2.enabled must survive — it belongs to cap-x2, not cap-x',
|
|
);
|
|
assert.strictEqual(
|
|
result.values['x2.enabled'],
|
|
true,
|
|
'x2.enabled must have its own default (true)',
|
|
);
|
|
});
|
|
|
|
test("removing 'alpha' cap does not affect 'alphabeta.flag' cap", () => {
|
|
const registryAfterAlphaRemoved = {
|
|
'alphabeta.flag': boolSlice('cap-alphabeta', false),
|
|
'gamma.flag': boolSlice('cap-gamma', true),
|
|
};
|
|
|
|
const result = mergeFederatedConfig({
|
|
configSchema: registryAfterAlphaRemoved,
|
|
isCentralKey: neverCentral,
|
|
userConfig: {},
|
|
});
|
|
|
|
// alpha.flag not present (removed)
|
|
assert.ok(
|
|
!result.validKeys.includes('alpha.flag'),
|
|
'alpha.flag must not appear after cap-alpha removal',
|
|
);
|
|
|
|
// alphabeta.flag MUST be present (distinct capability)
|
|
assert.ok(
|
|
result.validKeys.includes('alphabeta.flag'),
|
|
'alphabeta.flag must survive removal of alpha capability',
|
|
);
|
|
assert.strictEqual(
|
|
result.values['alphabeta.flag'],
|
|
false,
|
|
'alphabeta.flag value must be false (its own default)',
|
|
);
|
|
|
|
// gamma.flag also unaffected
|
|
assert.ok(
|
|
result.validKeys.includes('gamma.flag'),
|
|
'gamma.flag must be unaffected by alpha removal',
|
|
);
|
|
assert.strictEqual(
|
|
result.values['gamma.flag'],
|
|
true,
|
|
'gamma.flag value must be true (its own default)',
|
|
);
|
|
});
|
|
});
|