@danmoisan/drm-copilot-mcp 1.0.16 → 1.0.18
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/out/mcp-server.js +1287 -548
- package/package.json +5 -4
- package/resources/claude-customizations/.claude/agent-memory/epic-orchestrator/MEMORY.md +9 -0
- package/resources/claude-customizations/.claude/agent-memory/epic-orchestrator/feedback_commit_push_memory_before_pr.md +17 -0
- package/resources/claude-customizations/.claude/agent-memory/orchestrator/MEMORY.md +1 -0
- package/resources/claude-customizations/.claude/agent-memory/orchestrator/feedback_commit_push_memory_before_pr.md +16 -0
- package/resources/claude-customizations/.claude/agents/legacy-parity-analyst.md +64 -0
- package/resources/claude-customizations/.claude/agents/migration-coverage-reviewer.md +64 -0
- package/resources/claude-customizations/.claude/agents/requirements-reconciler.md +63 -0
- package/resources/claude-customizations/.claude/agents/runtime-characterization-analyst.md +64 -0
- package/resources/claude-customizations/.claude/hooks/enforce-discovery-artifact-gate.ps1 +213 -0
- package/resources/claude-customizations/.claude/hooks/validate-discovery-artifact-gate.ps1 +237 -0
- package/resources/claude-customizations/.claude/hooks/validate-planner-output.ps1 +5 -5
- package/resources/claude-customizations/.claude/rules/shell.md +88 -0
- package/resources/claude-customizations/.claude/settings.json +8 -0
- package/resources/claude-customizations/.claude/skills/cleanup-merged-worktrees/SKILL.md +132 -0
- package/resources/claude-customizations/.claude/skills/discovery-behavior-reconciliation/SKILL.md +65 -0
- package/resources/claude-customizations/.claude/skills/discovery-coverage-ledger/SKILL.md +66 -0
- package/resources/claude-customizations/.claude/skills/discovery-parity-matrix/SKILL.md +63 -0
- package/resources/claude-customizations/.claude/skills/discovery-repo-inventory/SKILL.md +80 -0
- package/resources/claude-customizations/.claude/skills/discovery-runtime-characterization/SKILL.md +63 -0
- package/resources/claude-customizations/.claude/skills/discovery-validate-artifacts/SKILL.md +79 -0
- package/resources/claude-customizations/.claude/skills/discovery-workflow/SKILL.md +146 -0
- package/resources/claude-customizations/.claude/skills/execute-hard-lock/SKILL.md +1 -1
- package/resources/claude-customizations/pack-manifests/core.json +14 -0
- package/resources/codex-and-agents-customizations/.agents/skills/execute-hard-lock/SKILL.md +1 -1
- package/resources/codex-and-agents-customizations/.codex/config.toml +1 -1
- package/resources/config/orchestration-routing.json +0 -2
- package/resources/powershell/PoshQC/PoshQC.Testing.psm1 +24 -2
- package/resources/powershell/PoshQC/PoshQC.psm1 +32 -6
- package/resources/powershell/PoshQC/settings/pester.runsettings.psd1 +13 -0
- package/resources/templates/policy_audit/policy-audit.yyyy-MM-ddTHH-mm.md +3 -3
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: discovery-parity-matrix
|
|
3
|
+
description: 'Produce or refresh the parity matrix in the discovery workflow. Use when building the parity matrix from feature contracts and runtime characterization evidence and routing parity reasoning to the parity role. Fifth stage, after runtime characterization and before behavior reconciliation.'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Discovery Parity Matrix
|
|
7
|
+
|
|
8
|
+
Runs the parity stage of the discovery and parity-definition workflow. It
|
|
9
|
+
produces or refreshes the parity matrix by comparing the feature contracts
|
|
10
|
+
against the runtime characterization scenarios, so the workflow can measure how
|
|
11
|
+
closely the modern target reproduces the legacy behavior. All domain specificity
|
|
12
|
+
is read from the domain profile at runtime.
|
|
13
|
+
|
|
14
|
+
## When to Use This Skill
|
|
15
|
+
|
|
16
|
+
- Feature contracts and runtime characterization scenarios both exist.
|
|
17
|
+
- You need a current parity matrix before reconciling unspecified behavior.
|
|
18
|
+
|
|
19
|
+
## Prerequisites
|
|
20
|
+
|
|
21
|
+
- `discovery-coverage-ledger` and `discovery-runtime-characterization` have
|
|
22
|
+
completed.
|
|
23
|
+
- The domain profile is loaded and valid.
|
|
24
|
+
|
|
25
|
+
## Workflow
|
|
26
|
+
|
|
27
|
+
1. **Consume upstream artifacts.** Read the feature contracts (schema
|
|
28
|
+
`schemas/discovery/v1/feature-contract.schema.json`) and the runtime
|
|
29
|
+
characterization scenarios (schema
|
|
30
|
+
`schemas/discovery/v1/runtime-characterization-scenario.schema.json`).
|
|
31
|
+
|
|
32
|
+
2. **Produce or refresh the parity matrix.** Build the parity matrix conforming
|
|
33
|
+
to the schema `schemas/discovery/v1/parity-matrix.schema.json`, mapping each
|
|
34
|
+
feature contract to its characterized behavior and its current parity state.
|
|
35
|
+
When the matrix already exists, refresh it in place from the latest upstream
|
|
36
|
+
artifacts.
|
|
37
|
+
|
|
38
|
+
3. **Route parity reasoning.** Hand the matrix to the parity role for reasoning
|
|
39
|
+
about gaps and states (see `## Worker Routing`).
|
|
40
|
+
|
|
41
|
+
## Worker Routing
|
|
42
|
+
|
|
43
|
+
- Worker: `legacy-parity-analyst`
|
|
44
|
+
|
|
45
|
+
The parity role reasons about each parity-matrix entry, classifying parity state
|
|
46
|
+
and flagging gaps for behavior reconciliation.
|
|
47
|
+
|
|
48
|
+
## Validation
|
|
49
|
+
|
|
50
|
+
- Validate the parity matrix with `dev.discovery.validate-parity-matrix`.
|
|
51
|
+
- An empty error list is a pass. On any error, follow the direction in
|
|
52
|
+
`discovery-validate-artifacts`.
|
|
53
|
+
|
|
54
|
+
## Referenced Skills
|
|
55
|
+
|
|
56
|
+
- `discovery-workflow` — stage order and the canonical Referenced Contracts
|
|
57
|
+
registry.
|
|
58
|
+
- `discovery-validate-artifacts` — pass/fail semantics and error routing.
|
|
59
|
+
|
|
60
|
+
## Notes
|
|
61
|
+
|
|
62
|
+
- Parity gaps flagged here are the primary input to
|
|
63
|
+
`discovery-behavior-reconciliation`.
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: discovery-repo-inventory
|
|
3
|
+
description: 'Drive the language-neutral repository and project inventory analyzer for the discovery workflow. Use when running the inventory stage against the domain profile source and target roots, recording analyzer outputs under the profile artifacts root, and running stack-specific analyzers generically per the profile technology stack. Second stage after profile load.'
|
|
4
|
+
allowed-tools: Bash Read Glob Grep
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Discovery Repo Inventory
|
|
8
|
+
|
|
9
|
+
Runs the inventory stage of the discovery and parity-definition workflow. It
|
|
10
|
+
drives the language-neutral repository/project inventory analyzer against the
|
|
11
|
+
roots declared in the domain profile, records outputs under the profile's
|
|
12
|
+
artifact root, and then runs any stack-specific analyzers generically, without
|
|
13
|
+
naming any concrete technology. All domain specificity is read from the domain
|
|
14
|
+
profile at runtime.
|
|
15
|
+
|
|
16
|
+
## When to Use This Skill
|
|
17
|
+
|
|
18
|
+
- You have loaded the domain profile and are ready to inventory the legacy
|
|
19
|
+
source and the modern target.
|
|
20
|
+
- You need analyzer outputs recorded as evidence for the coverage stage.
|
|
21
|
+
|
|
22
|
+
## Prerequisites
|
|
23
|
+
|
|
24
|
+
- The domain profile loads via `dev.discovery.profile`.
|
|
25
|
+
- The analyzer framework CLI is available (referenced by name only; the full
|
|
26
|
+
registry lives in `discovery-workflow`).
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
1. **Load the domain profile.** Run `dev.discovery.profile` to load and echo the
|
|
31
|
+
consumer repository's `discovery-profile.yaml`. Read the following keys and
|
|
32
|
+
use them for every subsequent step; do not hard-code any of them:
|
|
33
|
+
- `legacy_source.root` — the legacy application source root.
|
|
34
|
+
- `target.root` — the modern target root.
|
|
35
|
+
- `artifacts.root` — where analyzer outputs and discovery artifacts are
|
|
36
|
+
recorded.
|
|
37
|
+
- `technology_stack` — the declared stack, used to select stack-specific
|
|
38
|
+
analyzers generically.
|
|
39
|
+
|
|
40
|
+
2. **Run the language-neutral inventory analyzer.** Drive the inventory command
|
|
41
|
+
(assumed `dev.discovery.inventory`; see the fan-in note below) against
|
|
42
|
+
`legacy_source.root` and `target.root`. Record all outputs under
|
|
43
|
+
`artifacts.root` following the profile's artifact conventions.
|
|
44
|
+
|
|
45
|
+
**Fan-in reconciliation assumption:** the inventory command name
|
|
46
|
+
`dev.discovery.inventory` is assumed and may be renamed when the analyzer
|
|
47
|
+
framework (epic #9006) lands. The canonical registry entry and this fragment
|
|
48
|
+
are the only two locations to reconcile; the canonical entry lives in
|
|
49
|
+
`discovery-workflow`.
|
|
50
|
+
|
|
51
|
+
3. **Run stack-specific analyzers generically.** For the declared
|
|
52
|
+
`technology_stack`, run any stack-specific analyzer commands documented by the
|
|
53
|
+
analyzer framework. Do not name a concrete analyzer or technology here; the
|
|
54
|
+
profile's `technology_stack` value selects the applicable analyzers at
|
|
55
|
+
runtime. Record their outputs under `artifacts.root` as well.
|
|
56
|
+
|
|
57
|
+
4. **Record evidence references.** Capture each analyzer output as an
|
|
58
|
+
evidence-reference instance so downstream stages can cite provenance.
|
|
59
|
+
|
|
60
|
+
## Validation
|
|
61
|
+
|
|
62
|
+
- Before the inventory stage begins, confirm the profile is valid with
|
|
63
|
+
`dev.discovery.validate-profile`.
|
|
64
|
+
- After recording evidence references, validate them with
|
|
65
|
+
`dev.discovery.validate-evidence-reference`.
|
|
66
|
+
- An empty error list is a pass. On any error, follow the direction in
|
|
67
|
+
`discovery-validate-artifacts`, which owns the canonical validation-gate
|
|
68
|
+
mechanics.
|
|
69
|
+
|
|
70
|
+
## Referenced Skills
|
|
71
|
+
|
|
72
|
+
- `discovery-workflow` — stage order and the canonical Referenced Contracts
|
|
73
|
+
registry (analyzer command, agent slugs, schema paths, validators).
|
|
74
|
+
- `discovery-validate-artifacts` — pass/fail semantics and error routing.
|
|
75
|
+
|
|
76
|
+
## Notes
|
|
77
|
+
|
|
78
|
+
- This skill introduces no domain-specific identifier. Source root, target root,
|
|
79
|
+
artifact root, and stack are all read from the domain profile at runtime.
|
|
80
|
+
- Outputs from this stage feed `discovery-coverage-ledger`.
|
package/resources/claude-customizations/.claude/skills/discovery-runtime-characterization/SKILL.md
ADDED
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: discovery-runtime-characterization
|
|
3
|
+
description: 'Produce runtime characterization scenarios and evidence references in the discovery workflow. Use when characterizing observed runtime behavior of the legacy application into scenarios with supporting evidence and routing analysis to the runtime role. Fourth stage, after coverage and before parity.'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Discovery Runtime Characterization
|
|
7
|
+
|
|
8
|
+
Runs the runtime characterization stage of the discovery and parity-definition
|
|
9
|
+
workflow. It captures observed runtime behavior of the legacy application as
|
|
10
|
+
characterization scenarios, each backed by evidence references, so that parity
|
|
11
|
+
analysis can compare intended contracts against observed behavior. All domain
|
|
12
|
+
specificity is read from the domain profile at runtime.
|
|
13
|
+
|
|
14
|
+
## When to Use This Skill
|
|
15
|
+
|
|
16
|
+
- Feature contracts and the coverage ledger exist from the coverage stage.
|
|
17
|
+
- You need documented runtime behavior scenarios before building the parity
|
|
18
|
+
matrix.
|
|
19
|
+
|
|
20
|
+
## Prerequisites
|
|
21
|
+
|
|
22
|
+
- `discovery-coverage-ledger` has completed.
|
|
23
|
+
- The domain profile is loaded and valid.
|
|
24
|
+
|
|
25
|
+
## Workflow
|
|
26
|
+
|
|
27
|
+
1. **Produce characterization scenarios.** For each behavior requiring runtime
|
|
28
|
+
observation, produce a scenario conforming to the schema
|
|
29
|
+
`schemas/discovery/v1/runtime-characterization-scenario.schema.json`. Each
|
|
30
|
+
scenario records the observed runtime behavior in a domain-neutral form.
|
|
31
|
+
|
|
32
|
+
2. **Record evidence references.** Attach evidence to each scenario as
|
|
33
|
+
evidence-reference instances conforming to the schema
|
|
34
|
+
`schemas/discovery/v1/evidence-reference.schema.json`, so the provenance of
|
|
35
|
+
each observation is traceable.
|
|
36
|
+
|
|
37
|
+
3. **Route analysis.** Hand the scenarios to the runtime role for analysis (see
|
|
38
|
+
`## Worker Routing`).
|
|
39
|
+
|
|
40
|
+
## Worker Routing
|
|
41
|
+
|
|
42
|
+
- Worker: `runtime-characterization-analyst`
|
|
43
|
+
|
|
44
|
+
The runtime role analyzes and confirms each characterization scenario and its
|
|
45
|
+
evidence before the workflow proceeds to parity.
|
|
46
|
+
|
|
47
|
+
## Validation
|
|
48
|
+
|
|
49
|
+
- Validate scenarios with `dev.discovery.validate-runtime-scenario`.
|
|
50
|
+
- Validate evidence references with `dev.discovery.validate-evidence-reference`.
|
|
51
|
+
- An empty error list is a pass. On any error, follow the direction in
|
|
52
|
+
`discovery-validate-artifacts`.
|
|
53
|
+
|
|
54
|
+
## Referenced Skills
|
|
55
|
+
|
|
56
|
+
- `discovery-workflow` — stage order and the canonical Referenced Contracts
|
|
57
|
+
registry.
|
|
58
|
+
- `discovery-validate-artifacts` — pass/fail semantics and error routing.
|
|
59
|
+
|
|
60
|
+
## Notes
|
|
61
|
+
|
|
62
|
+
- Scenarios and evidence references from this stage are consumed by
|
|
63
|
+
`discovery-parity-matrix`.
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: discovery-validate-artifacts
|
|
3
|
+
description: 'Canonical validation-gate mechanics for the discovery workflow. Use when running the per-artifact discovery validators after each stage and the completion gate at the end, interpreting the empty-error-list pass semantics, and routing any validator error back to the owning stage skill. Seventh and final stage.'
|
|
4
|
+
allowed-tools: Bash Read
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Discovery Validate Artifacts
|
|
8
|
+
|
|
9
|
+
Owns the canonical validation-gate mechanics for the discovery and
|
|
10
|
+
parity-definition workflow. Each discovery artifact is validated against its
|
|
11
|
+
schema by a `dev.discovery.validate-*` console script after its owning stage,
|
|
12
|
+
and `dev.discovery.validate-all` runs as the workflow completion gate. This skill
|
|
13
|
+
is the single canonical location for the pass/fail semantics; stage skills defer
|
|
14
|
+
to it by name.
|
|
15
|
+
|
|
16
|
+
## When to Use This Skill
|
|
17
|
+
|
|
18
|
+
- A stage has produced an artifact and you need to validate it before the next
|
|
19
|
+
stage proceeds.
|
|
20
|
+
- You have completed all stages and need to run the workflow completion gate.
|
|
21
|
+
- A validator reported errors and you need the routing rule back to the owning
|
|
22
|
+
stage skill.
|
|
23
|
+
|
|
24
|
+
## Prerequisites
|
|
25
|
+
|
|
26
|
+
- The relevant discovery artifacts exist under the profile's artifact root.
|
|
27
|
+
- The validator console scripts are available (registry in `discovery-workflow`).
|
|
28
|
+
|
|
29
|
+
## Pass/Fail Semantics
|
|
30
|
+
|
|
31
|
+
Every `dev.discovery.validate-*` invocation yields a `list[str]` of error
|
|
32
|
+
messages. An empty list is a pass; a non-empty list is a failure whose entries
|
|
33
|
+
name the exact problems. The validators never mutate the artifacts they check.
|
|
34
|
+
|
|
35
|
+
## Per-Stage Validators
|
|
36
|
+
|
|
37
|
+
Run each validator after its owning stage produces its artifact. On a non-empty
|
|
38
|
+
error list, return to the named owning stage skill, correct the artifact, and
|
|
39
|
+
re-run the validator until the list is empty.
|
|
40
|
+
|
|
41
|
+
| Validator | Validates schema | Owning stage skill |
|
|
42
|
+
|---|---|---|
|
|
43
|
+
| `dev.discovery.validate-profile` | (domain profile) | `discovery-repo-inventory` |
|
|
44
|
+
| `dev.discovery.validate-evidence-reference` | `schemas/discovery/v1/evidence-reference.schema.json` | `discovery-repo-inventory`, `discovery-runtime-characterization` |
|
|
45
|
+
| `dev.discovery.validate-feature-contract` | `schemas/discovery/v1/feature-contract.schema.json` | `discovery-coverage-ledger` |
|
|
46
|
+
| `dev.discovery.validate-coverage-ledger` | `schemas/discovery/v1/coverage-ledger.schema.json` | `discovery-coverage-ledger` |
|
|
47
|
+
| `dev.discovery.validate-runtime-scenario` | `schemas/discovery/v1/runtime-characterization-scenario.schema.json` | `discovery-runtime-characterization` |
|
|
48
|
+
| `dev.discovery.validate-parity-matrix` | `schemas/discovery/v1/parity-matrix.schema.json` | `discovery-parity-matrix` |
|
|
49
|
+
| `dev.discovery.validate-unspecified-behavior` | `schemas/discovery/v1/unspecified-behavior-record.schema.json` | `discovery-behavior-reconciliation` |
|
|
50
|
+
| `dev.discovery.validate-product-decision` | `schemas/discovery/v1/product-decision-record.schema.json` | `discovery-behavior-reconciliation` |
|
|
51
|
+
|
|
52
|
+
## Completion Gate
|
|
53
|
+
|
|
54
|
+
After all stages pass their per-stage validators, run
|
|
55
|
+
`dev.discovery.validate-all` as the workflow completion gate. It validates the
|
|
56
|
+
full artifact set across all seven schemas under `schemas/discovery/v1/`:
|
|
57
|
+
|
|
58
|
+
- `schemas/discovery/v1/feature-contract.schema.json`
|
|
59
|
+
- `schemas/discovery/v1/coverage-ledger.schema.json`
|
|
60
|
+
- `schemas/discovery/v1/runtime-characterization-scenario.schema.json`
|
|
61
|
+
- `schemas/discovery/v1/parity-matrix.schema.json`
|
|
62
|
+
- `schemas/discovery/v1/unspecified-behavior-record.schema.json`
|
|
63
|
+
- `schemas/discovery/v1/product-decision-record.schema.json`
|
|
64
|
+
- `schemas/discovery/v1/evidence-reference.schema.json`
|
|
65
|
+
|
|
66
|
+
An empty error list from `dev.discovery.validate-all` means the workflow is
|
|
67
|
+
complete. A non-empty list names the exact artifact and problem; route each entry
|
|
68
|
+
back to its owning stage skill using the per-stage table above, correct the
|
|
69
|
+
artifact, and re-run the gate.
|
|
70
|
+
|
|
71
|
+
## Referenced Skills
|
|
72
|
+
|
|
73
|
+
- `discovery-workflow` — stage order and the canonical Referenced Contracts
|
|
74
|
+
registry (analyzer command, agent slugs, schema paths, validators).
|
|
75
|
+
|
|
76
|
+
## Notes
|
|
77
|
+
|
|
78
|
+
- This skill names no domain-specific identifier; artifact locations are read
|
|
79
|
+
from the domain profile at runtime.
|
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: discovery-workflow
|
|
3
|
+
description: 'Umbrella sequencing skill for the domain-neutral legacy discovery and parity-definition workflow. Use when onboarding or running the end-to-end discovery workflow across inventory, coverage, runtime characterization, parity, behavior reconciliation, and the validation gate, and when reconciling upstream analyzer and agent contract names. Holds the canonical Referenced Contracts registry.'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Discovery Workflow
|
|
7
|
+
|
|
8
|
+
Sequences the reusable, domain-neutral discovery and parity-definition workflow
|
|
9
|
+
end to end. This skill is the entry point: it establishes the stage order,
|
|
10
|
+
directs each stage to its owning skill, and holds the single canonical registry
|
|
11
|
+
of upstream contract names (analyzer CLI commands, agent slugs, schema paths,
|
|
12
|
+
and validators).
|
|
13
|
+
|
|
14
|
+
All domain specificity is read at runtime from the consumer repository's domain
|
|
15
|
+
profile (`discovery-profile.yaml`) via `dev.discovery.profile`. This skill names
|
|
16
|
+
no concrete repository, path, or technology stack.
|
|
17
|
+
|
|
18
|
+
## When to Use This Skill
|
|
19
|
+
|
|
20
|
+
- You are onboarding the discovery and parity-definition workflow in a consumer
|
|
21
|
+
repository and need the documented stage order.
|
|
22
|
+
- You need the canonical list of upstream contract names to reconcile a renamed
|
|
23
|
+
analyzer command or agent slug at epic fan-in.
|
|
24
|
+
- You need to know which stage skill owns which artifact and validator.
|
|
25
|
+
|
|
26
|
+
## Prerequisites
|
|
27
|
+
|
|
28
|
+
- A `discovery-profile.yaml` domain profile exists in the consumer repository and
|
|
29
|
+
loads cleanly via `dev.discovery.profile`.
|
|
30
|
+
- The analyzer framework CLI and the four generic agent roles are available in
|
|
31
|
+
the consumer environment (referenced here by name only).
|
|
32
|
+
|
|
33
|
+
## Stage Order
|
|
34
|
+
|
|
35
|
+
Run the workflow in this fixed order. Each stage validates its artifacts before
|
|
36
|
+
the next stage proceeds:
|
|
37
|
+
|
|
38
|
+
1. **profile** — load and echo the domain profile via `dev.discovery.profile`.
|
|
39
|
+
2. **inventory** — drive the language-neutral repository/project inventory
|
|
40
|
+
analyzer (`discovery-repo-inventory`).
|
|
41
|
+
3. **coverage** — produce feature contracts and the coverage ledger
|
|
42
|
+
(`discovery-coverage-ledger`).
|
|
43
|
+
4. **runtime** — produce runtime characterization scenarios and evidence
|
|
44
|
+
references (`discovery-runtime-characterization`).
|
|
45
|
+
5. **parity** — produce or refresh the parity matrix (`discovery-parity-matrix`).
|
|
46
|
+
6. **reconciliation** — capture unspecified or contradictory behavior and
|
|
47
|
+
reconcile it into product decisions (`discovery-behavior-reconciliation`).
|
|
48
|
+
7. **validation gate** — run the per-stage validators and the completion gate
|
|
49
|
+
(`discovery-validate-artifacts`).
|
|
50
|
+
|
|
51
|
+
Compact form: profile -> inventory -> coverage -> runtime -> parity ->
|
|
52
|
+
reconciliation -> validation gate.
|
|
53
|
+
|
|
54
|
+
## Worker Routing
|
|
55
|
+
|
|
56
|
+
The four generic agent roles are routed by slug from their owning stage skills.
|
|
57
|
+
The routing table below is the canonical mapping; each stage skill repeats only
|
|
58
|
+
the single slug it routes to.
|
|
59
|
+
|
|
60
|
+
| Stage skill | Agent slug |
|
|
61
|
+
|---|---|
|
|
62
|
+
| `discovery-coverage-ledger` | `migration-coverage-reviewer` |
|
|
63
|
+
| `discovery-runtime-characterization` | `runtime-characterization-analyst` |
|
|
64
|
+
| `discovery-parity-matrix` | `legacy-parity-analyst` |
|
|
65
|
+
| `discovery-behavior-reconciliation` | `requirements-reconciler` |
|
|
66
|
+
|
|
67
|
+
## Referenced Contracts
|
|
68
|
+
|
|
69
|
+
This registry is the single canonical location for upstream contract names.
|
|
70
|
+
Stage skills name only the specific contract(s) they use and defer to this
|
|
71
|
+
registry for the full set. Indirect reference by skill name is not duplication.
|
|
72
|
+
|
|
73
|
+
### Domain profile (config contract, issue #360 / epic #9001)
|
|
74
|
+
|
|
75
|
+
- Config artifact: `discovery-profile.yaml`.
|
|
76
|
+
- CLI: `dev.discovery.profile`.
|
|
77
|
+
|
|
78
|
+
### Schemas (issue #359 / epic #9002)
|
|
79
|
+
|
|
80
|
+
Seven schemas under `schemas/discovery/v1/`:
|
|
81
|
+
|
|
82
|
+
- `schemas/discovery/v1/feature-contract.schema.json`
|
|
83
|
+
- `schemas/discovery/v1/coverage-ledger.schema.json`
|
|
84
|
+
- `schemas/discovery/v1/runtime-characterization-scenario.schema.json`
|
|
85
|
+
- `schemas/discovery/v1/parity-matrix.schema.json`
|
|
86
|
+
- `schemas/discovery/v1/unspecified-behavior-record.schema.json`
|
|
87
|
+
- `schemas/discovery/v1/product-decision-record.schema.json`
|
|
88
|
+
- `schemas/discovery/v1/evidence-reference.schema.json`
|
|
89
|
+
|
|
90
|
+
### Validators (issue #361 / epic #9003)
|
|
91
|
+
|
|
92
|
+
Nine `dev.discovery.validate-*` console scripts. Each yields a `list[str]` of
|
|
93
|
+
errors; an empty list is a pass.
|
|
94
|
+
|
|
95
|
+
- `dev.discovery.validate-profile`
|
|
96
|
+
- `dev.discovery.validate-feature-contract`
|
|
97
|
+
- `dev.discovery.validate-coverage-ledger`
|
|
98
|
+
- `dev.discovery.validate-runtime-scenario`
|
|
99
|
+
- `dev.discovery.validate-parity-matrix`
|
|
100
|
+
- `dev.discovery.validate-unspecified-behavior`
|
|
101
|
+
- `dev.discovery.validate-product-decision`
|
|
102
|
+
- `dev.discovery.validate-evidence-reference`
|
|
103
|
+
- `dev.discovery.validate-all`
|
|
104
|
+
|
|
105
|
+
### Analyzer framework (epic #9006, in preparation)
|
|
106
|
+
|
|
107
|
+
- Language-neutral repository/project inventory command: `dev.discovery.inventory`.
|
|
108
|
+
|
|
109
|
+
**Fan-in reconciliation assumption:** the inventory command name
|
|
110
|
+
`dev.discovery.inventory` is assumed. It is not fixed by the prepared upstream
|
|
111
|
+
summaries and is the epic #9006 owner's decision. This assumption is isolated
|
|
112
|
+
to this single registry line plus one fragment in `discovery-repo-inventory`.
|
|
113
|
+
If #9006 lands a different command name, update those two locations only.
|
|
114
|
+
|
|
115
|
+
### Agent roles (epic #9007, in preparation)
|
|
116
|
+
|
|
117
|
+
Four generic agent personas, referenced by slug in the Worker Routing table
|
|
118
|
+
above:
|
|
119
|
+
|
|
120
|
+
- `legacy-parity-analyst`
|
|
121
|
+
- `runtime-characterization-analyst`
|
|
122
|
+
- `requirements-reconciler`
|
|
123
|
+
- `migration-coverage-reviewer`
|
|
124
|
+
|
|
125
|
+
**Fan-in reconciliation assumption:** the four agent slugs are assumed to be
|
|
126
|
+
the kebab-case of the persona titles. Final slugs are the epic #9007 owner's
|
|
127
|
+
decision. The assumption is isolated to this registry and the per-stage
|
|
128
|
+
`## Worker Routing` fragments; reconciling a renamed slug at fan-in is a
|
|
129
|
+
bounded edit.
|
|
130
|
+
|
|
131
|
+
## Referenced Skills
|
|
132
|
+
|
|
133
|
+
- `discovery-repo-inventory` — inventory stage mechanics.
|
|
134
|
+
- `discovery-coverage-ledger` — coverage stage mechanics.
|
|
135
|
+
- `discovery-runtime-characterization` — runtime stage mechanics.
|
|
136
|
+
- `discovery-parity-matrix` — parity stage mechanics.
|
|
137
|
+
- `discovery-behavior-reconciliation` — reconciliation stage mechanics.
|
|
138
|
+
- `discovery-validate-artifacts` — canonical validation-gate mechanics.
|
|
139
|
+
|
|
140
|
+
## Notes
|
|
141
|
+
|
|
142
|
+
- No skill in this workflow asserts the existence of upstream analyzer or agent
|
|
143
|
+
files; upstream contracts are referenced by name only, so this workflow stays
|
|
144
|
+
correct regardless of upstream merge order.
|
|
145
|
+
- Domain specificity (source and target roots, technology stack, artifact
|
|
146
|
+
conventions) is read from the domain profile at runtime, never hard-coded.
|
|
@@ -34,7 +34,7 @@ Call the extension's resolver as the first action:
|
|
|
34
34
|
- Tool: `mcp__drm-copilot__resolve_execute_hard_lock_prompt`
|
|
35
35
|
- Parameters:
|
|
36
36
|
- `target` (required): the plan-of-record path (`${plan-path}`).
|
|
37
|
-
- `workspace_root` (
|
|
37
|
+
- `workspace_root` (required): the absolute root of the calling agent's checkout or worktree. The MCP server cannot infer the caller's checkout, so this value must be passed explicitly.
|
|
38
38
|
|
|
39
39
|
On success, the response contains an `artifacts` array whose first entry is the absolute path of a file containing the resolved hard-lock prompt (produced by the extension passing `--output` and `--quiet` to the bundled Python resolver).
|
|
40
40
|
|
|
@@ -11,13 +11,18 @@
|
|
|
11
11
|
".claude/agents/epic-review.md",
|
|
12
12
|
".claude/agents/feature-review.md",
|
|
13
13
|
".claude/agents/human-exception-runbook.md",
|
|
14
|
+
".claude/agents/legacy-parity-analyst.md",
|
|
15
|
+
".claude/agents/migration-coverage-reviewer.md",
|
|
14
16
|
".claude/agents/orchestrator.md",
|
|
15
17
|
".claude/agents/prd-feature.md",
|
|
18
|
+
".claude/agents/requirements-reconciler.md",
|
|
19
|
+
".claude/agents/runtime-characterization-analyst.md",
|
|
16
20
|
".claude/agents/staged-review.md",
|
|
17
21
|
".claude/agents/status-updater.md",
|
|
18
22
|
".claude/agents/task-researcher.md",
|
|
19
23
|
".claude/hooks/enforce-checkpoint-monotonic.ps1",
|
|
20
24
|
".claude/hooks/enforce-completion-consistency.ps1",
|
|
25
|
+
".claude/hooks/enforce-discovery-artifact-gate.ps1",
|
|
21
26
|
".claude/hooks/enforce-epic-invocation-origin.ps1",
|
|
22
27
|
".claude/hooks/enforce-epic-merge-gate.ps1",
|
|
23
28
|
".claude/hooks/enforce-epic-wave-barrier.ps1",
|
|
@@ -32,6 +37,7 @@
|
|
|
32
37
|
".claude/hooks/enforce-promotion-mcp-only.ps1",
|
|
33
38
|
".claude/hooks/persist-session-id.ps1",
|
|
34
39
|
".claude/hooks/validate-bash.ps1",
|
|
40
|
+
".claude/hooks/validate-discovery-artifact-gate.ps1",
|
|
35
41
|
".claude/hooks/validate-executor-output.ps1",
|
|
36
42
|
".claude/hooks/validate-feature-review-coverage.ps1",
|
|
37
43
|
".claude/hooks/validate-orchestrator-output.ps1",
|
|
@@ -49,7 +55,15 @@
|
|
|
49
55
|
".claude/rules/tonality.md",
|
|
50
56
|
".claude/skills/acceptance-criteria-tracking/SKILL.md",
|
|
51
57
|
".claude/skills/atomic-plan-contract/SKILL.md",
|
|
58
|
+
".claude/skills/cleanup-merged-worktrees/SKILL.md",
|
|
52
59
|
".claude/skills/commit-message/SKILL.md",
|
|
60
|
+
".claude/skills/discovery-behavior-reconciliation/SKILL.md",
|
|
61
|
+
".claude/skills/discovery-coverage-ledger/SKILL.md",
|
|
62
|
+
".claude/skills/discovery-parity-matrix/SKILL.md",
|
|
63
|
+
".claude/skills/discovery-repo-inventory/SKILL.md",
|
|
64
|
+
".claude/skills/discovery-runtime-characterization/SKILL.md",
|
|
65
|
+
".claude/skills/discovery-validate-artifacts/SKILL.md",
|
|
66
|
+
".claude/skills/discovery-workflow/SKILL.md",
|
|
53
67
|
".claude/skills/epic-orchestrate/SKILL.md",
|
|
54
68
|
".claude/skills/epic-plan/SKILL.md",
|
|
55
69
|
".claude/skills/epic-run/SKILL.md",
|
|
@@ -31,7 +31,7 @@ Call the extension's resolver as the first action:
|
|
|
31
31
|
- Tool: `mcp__drm-copilot__resolve_execute_hard_lock_prompt`
|
|
32
32
|
- Parameters:
|
|
33
33
|
- `target` (required): the plan-of-record path (`${plan-path}`).
|
|
34
|
-
- `workspace_root` (
|
|
34
|
+
- `workspace_root` (required): the absolute root of the calling agent's checkout or worktree. The MCP server cannot infer the caller's checkout, so this value must be passed explicitly.
|
|
35
35
|
|
|
36
36
|
On success, the response contains an `artifacts` array whose first entry is the absolute path of a file containing the resolved hard-lock prompt (produced by the extension passing `--output` and `--quiet` to the bundled Python resolver).
|
|
37
37
|
|
|
@@ -160,7 +160,9 @@ function Invoke-PoshQCTest {
|
|
|
160
160
|
[scriptblock] $EnsureModule = {
|
|
161
161
|
param([string] $Name, [string] $ErrorMessage)
|
|
162
162
|
if (-not (Get-Module -ListAvailable -Name $Name)) { throw $ErrorMessage }
|
|
163
|
-
Import
|
|
163
|
+
# Import globally so Pester's Describe/It/Mock resolve in test containers that the
|
|
164
|
+
# default $InvokePester trampoline now hosts in the global session state (issue #392).
|
|
165
|
+
Import-Module $Name -Global -ErrorAction Stop
|
|
164
166
|
},
|
|
165
167
|
[scriptblock] $TestPathExists = { param([string] $Path) Test-Path $Path },
|
|
166
168
|
[scriptblock] $LoadSettings = { param([string] $Path) Import-PowerShellDataFile -Path $Path },
|
|
@@ -256,7 +258,27 @@ function Invoke-PoshQCTest {
|
|
|
256
258
|
# Use Write-Information so the replayed summary stays visible while respecting approved verbs.
|
|
257
259
|
Write-Information $Message -InformationAction Continue
|
|
258
260
|
},
|
|
259
|
-
[scriptblock] $InvokePester = {
|
|
261
|
+
[scriptblock] $InvokePester = {
|
|
262
|
+
param($Config)
|
|
263
|
+
# Host the Pester run in the global session state so discovered test containers do
|
|
264
|
+
# not execute inside this module's session state. This makes the bundled entry path
|
|
265
|
+
# (module pre-imported, then Invoke-PoshQCTest -> Invoke-Pester) match the passing
|
|
266
|
+
# direct run, and lets BeforeAll module guards in test files safely remove/re-import
|
|
267
|
+
# same-named modules mid-run without orphaning the run's hosting session state
|
|
268
|
+
# (issue #392). [scriptblock]::Create builds an unbound scriptblock so the installed
|
|
269
|
+
# global function is not bound to this module's session state; the try/finally pair
|
|
270
|
+
# removes the temporary global function so no state leaks between suite invocations.
|
|
271
|
+
$trampoline = [scriptblock]::Create('param($c) Invoke-Pester -Configuration $c')
|
|
272
|
+
$null = New-Item -Path 'function:global:Invoke-PoshQCPesterRun' -Value $trampoline -Force
|
|
273
|
+
try {
|
|
274
|
+
Invoke-PoshQCPesterRun $Config
|
|
275
|
+
} finally {
|
|
276
|
+
# Remove by the 'Function:\' provider path; a 'function:global:'-qualified path
|
|
277
|
+
# is honored by New-Item but silently no-ops on Remove-Item, which would leak the
|
|
278
|
+
# trampoline between suite invocations in a persistent host (issue #392).
|
|
279
|
+
Remove-Item -Path 'Function:\Invoke-PoshQCPesterRun' -Force -ErrorAction SilentlyContinue
|
|
280
|
+
}
|
|
281
|
+
},
|
|
260
282
|
[scriptblock] $CopyCoverage = {
|
|
261
283
|
param([string] $CoveragePath, [string] $RepoRoot, [string] $KoveragePath)
|
|
262
284
|
Convert-PoshQCCoverageToRelative -InputPath $CoveragePath -OutputPath $KoveragePath -RepoRoot $RepoRoot
|
|
@@ -89,6 +89,27 @@ function Install-PoshQCTool {
|
|
|
89
89
|
# [scriptblock]::Create((Get-Content -Raw)) approach produced scriptblocks with
|
|
90
90
|
# no source file, so breakpoints never bound and PoshQC.ScanConfig.psm1 fell
|
|
91
91
|
# outside the coverage denominator. Parse errors fail module import fast.
|
|
92
|
+
#
|
|
93
|
+
# issue #392 remediation cycle 2: re-parsing and re-compiling a fresh ScriptBlock
|
|
94
|
+
# for each sub-module on every Import-Module -Force made Pester's code-coverage
|
|
95
|
+
# merge lose already-recorded hit credit for previously covered lines of the
|
|
96
|
+
# re-compiled files (per-file LINE coverage of PoshQC.Testing.psm1 regressed from
|
|
97
|
+
# 149/195 to 131/195 across a bundled run). To avoid that re-parse/re-compile
|
|
98
|
+
# churn, the parsed ScriptBlock for each sub-module is cached in a process-lifetime
|
|
99
|
+
# AppDomain data slot keyed by absolute path, so ParseFile/GetScriptBlock runs at
|
|
100
|
+
# most once per sub-module per PowerShell process. Dot-sourcing still runs on
|
|
101
|
+
# every -Force reimport, so functions rebind into each new module session state and
|
|
102
|
+
# the test module-collision guards keep detecting/removing a mismatched instance.
|
|
103
|
+
# The AppDomain slot (not a $global: variable, which PSAvoidGlobalVars forbids)
|
|
104
|
+
# provides the process-lifetime persistence that -Force (which discards the
|
|
105
|
+
# module's own script scope each time) does not. A cache-miss parse error still
|
|
106
|
+
# fails module import fast.
|
|
107
|
+
$script:PoshQCSubModuleCacheKey = 'PoshQC.ParsedSubModuleScriptBlocks'
|
|
108
|
+
$subModuleCache = [System.AppDomain]::CurrentDomain.GetData($script:PoshQCSubModuleCacheKey)
|
|
109
|
+
if (-not $subModuleCache) {
|
|
110
|
+
$subModuleCache = @{}
|
|
111
|
+
[System.AppDomain]::CurrentDomain.SetData($script:PoshQCSubModuleCacheKey, $subModuleCache)
|
|
112
|
+
}
|
|
92
113
|
foreach ($subModuleName in @(
|
|
93
114
|
'PoshQC.FileDiscovery.psm1',
|
|
94
115
|
'PoshQC.ScanConfig.psm1',
|
|
@@ -96,13 +117,18 @@ foreach ($subModuleName in @(
|
|
|
96
117
|
'PoshQC.Testing.psm1'
|
|
97
118
|
)) {
|
|
98
119
|
$subModulePath = Join-Path $script:ModuleRoot $subModuleName
|
|
99
|
-
$
|
|
100
|
-
$
|
|
101
|
-
$
|
|
102
|
-
|
|
103
|
-
|
|
120
|
+
$cachedScriptBlock = $subModuleCache[$subModulePath]
|
|
121
|
+
if (-not $cachedScriptBlock) {
|
|
122
|
+
$parseErrors = $null
|
|
123
|
+
$ast = [System.Management.Automation.Language.Parser]::ParseFile(
|
|
124
|
+
$subModulePath, [ref]$null, [ref]$parseErrors)
|
|
125
|
+
if ($parseErrors) {
|
|
126
|
+
throw "Failed to parse sub-module '$subModuleName': $($parseErrors -join '; ')"
|
|
127
|
+
}
|
|
128
|
+
$cachedScriptBlock = $ast.GetScriptBlock()
|
|
129
|
+
$subModuleCache[$subModulePath] = $cachedScriptBlock
|
|
104
130
|
}
|
|
105
|
-
.
|
|
131
|
+
. $cachedScriptBlock
|
|
106
132
|
}
|
|
107
133
|
|
|
108
134
|
Set-Alias -Name Install-PoshQCTools -Value Install-PoshQCTool
|
|
@@ -82,6 +82,19 @@
|
|
|
82
82
|
# to AST-based scriptblocks (Parser::ParseFile(...).GetScriptBlock()) so Pester
|
|
83
83
|
# coverage breakpoints bind to the on-disk source file.
|
|
84
84
|
'scripts/powershell/PoshQC/PoshQC.ScanConfig.psm1'
|
|
85
|
+
# Issue #357 remediation cycle 1 (fix #1): measure the atomic-planner SubagentStop
|
|
86
|
+
# hook so its Pester coverage is captured in the canonical artifact.
|
|
87
|
+
'.claude/hooks/validate-planner-output.ps1'
|
|
88
|
+
# Issue #366 added the discovery-artifact completion-gate hooks (PreToolUse and
|
|
89
|
+
# SubagentStop); measured here so the new production hooks are not excluded from
|
|
90
|
+
# coverage.
|
|
91
|
+
'.claude/hooks/enforce-discovery-artifact-gate.ps1'
|
|
92
|
+
'.claude/hooks/validate-discovery-artifact-gate.ps1'
|
|
93
|
+
# Issue #392 changed the Invoke-PoshQCTest default seams ($EnsureModule -Global
|
|
94
|
+
# import and the global-session-state $InvokePester trampoline) so the bundled
|
|
95
|
+
# entry path hosts the Pester run in the global session state; measured here so
|
|
96
|
+
# the fix produces real per-file changed-line coverage evidence.
|
|
97
|
+
'scripts/powershell/PoshQC/PoshQC.Testing.psm1'
|
|
85
98
|
)
|
|
86
99
|
# Optional: don't fail the run on coverage percentage
|
|
87
100
|
CoveragePercentTarget = 0
|
|
@@ -275,9 +275,9 @@ Repeat one bullet per in-scope language that has coverage requirements. Keep the
|
|
|
275
275
|
|
|
276
276
|
| Requirement | Status | Evidence |
|
|
277
277
|
|------------|--------|----------|
|
|
278
|
-
| **Formatting with shfmt** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `
|
|
279
|
-
| **Linting with shellcheck** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `
|
|
280
|
-
| **Testing with bats** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `
|
|
278
|
+
| **Formatting with shfmt** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `bash scripts/bash/shell-qc.sh format`<br>**Result:** [Describe result] |
|
|
279
|
+
| **Linting with shellcheck** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `bash scripts/bash/shell-qc.sh check`<br>**Result:** [Describe result] |
|
|
280
|
+
| **Testing with bats** | [✅/❌/N/A] [PASS/FAIL/N/A] | **Command:** `bash scripts/bash/shell-qc.sh test`<br>**Result:** [Describe result or N/A if no tests] |
|
|
281
281
|
|
|
282
282
|
#### 3C.2 Bash Script Design
|
|
283
283
|
|