hatch3r 1.8.0 → 2.0.0

package/{rules → dist/content/rules}/hatch3r-container-hardening.md

@@ -2,8 +2,10 @@
 id: hatch3r-container-hardening
 type: rule
 description: Container image hardening — digest pinning, distroless / Wolfi base, non-root user, SBOM-in-image, cosign signing + verification, multi-stage builds, CVE scanning
-scope: "**/Dockerfile*,**/docker-compose*,**/*.containerfile,**/charts/**,**/k8s/**,**/kubernetes/**,**/manifests/**"
-tags: [security, devops]
+scope: conditional
+globs: "**/Dockerfile*,**/docker-compose*,**/*.containerfile,**/charts/**,**/k8s/**,**/kubernetes/**,**/manifests/**"
+tags: [devops, floor:security]
+precedence: high
 quality_charter: agents/shared/quality-charter.md
 cache_friendly: true
 ---
@@ -50,6 +52,8 @@ Every image carries a CycloneDX 1.6 SBOM, generated at build time and either emb
 
 ## Image Signing — cosign
 
+> Maturity tier: team+ — solo projects with no external consumers may defer signing. Cosign keyless + admission enforcement becomes mandatory once images are pulled by anyone outside the build pipeline.
+
 Every image is signed with cosign keyless mode via OIDC. Sigstore Fulcio issues a short-lived signing certificate scoped to the workflow identity; Rekor records the signature for tamper-evident audit.
 
 - Sign in CI: `cosign sign --yes <registry>/<image>@<digest>`. Workflow grants `id-token: write` permission; no long-lived signing key.
@@ -58,6 +62,8 @@ Every image is signed with cosign keyless mode via OIDC. Sigstore Fulcio issues
 
 ## CVE Scanning in CI
 
+> Maturity tier: team+ — solo projects may run a single scanner ad hoc. Two-scanner CI gating with suppression lifecycle earns its cost once a team owns the release pipeline.
+
 Two scanners are run per image build: `trivy` for breadth (Wolfi advisory database, OS+language deps) and `grype` for Chainguard parity. Release is blocked on unpatched Critical or High CVEs without a documented suppression record.
 
 - `trivy image --severity HIGH,CRITICAL --exit-code 1 <image>:<tag>` fails the job on any High/Critical.
@@ -75,6 +81,8 @@ The same digest-not-tag rule extends beyond `FROM` lines to every place the imag
 
 ## Reproducible Builds
 
+> Maturity tier: scaleup+ — team projects may defer the `repro-build` verification step until a compliance or supply-chain audit requests it. Solo and team projects still pin syntax + package versions; the digest-comparison gate is the scaleup add.
+
 Build inputs are pinned so the same `git checkout` produces the same image digest.
 
 - `# syntax=docker/dockerfile:1.<minor>.<patch>` — pin to a specific BuildKit syntax version.
@@ -109,6 +117,8 @@ Runtime image targets under 200 MB compressed. Builds exceeding 500 MB compresse
 
 ## Verification Gate at Release
 
+> Maturity tier: team+ — solo projects may defer the full five-gate release block. The non-root + digest-pin gates remain mandatory at every tier; cosign verification, dual-scanner thresholds, and SBOM attachment fire once a team owns admission policy.
+
 Every release pipeline executes the following gates before publish, all green:
 
 - `cosign verify` against the workflow OIDC identity.
@@ -117,7 +127,7 @@ Every release pipeline executes the following gates before publish, all green:
 - Pod spec runs as non-root (`runAsNonRoot: true`), read-only root filesystem, dropped capabilities.
 - SBOM attached and downloadable via `cosign download sbom`.
 
-Cross-reference `agents/hatch3r-security-auditor.md` for runtime security audit; `agents/hatch3r-devops.md` for delivery integration; `rules/hatch3r-secrets-management.md` for OIDC trust-policy conditions; `rules/hatch3r-dependency-management.md` for SBOM tooling and SLSA provenance.
+Cross-reference `agents/hatch3r-security.md` (CQ3) for runtime security audit; `agents/hatch3r-devops.md` for delivery integration; `rules/hatch3r-secrets-management.md` for OIDC trust-policy conditions; `rules/hatch3r-dependency-management.md` for SBOM tooling and SLSA provenance.
 
 ## References
 

package/{rules → dist/content/rules}/hatch3r-container-hardening.mdc

@@ -2,6 +2,7 @@
 description: Container image hardening — digest pinning, distroless / Wolfi base, non-root user, SBOM-in-image, cosign signing + verification, multi-stage builds, CVE scanning
 globs: ["**/Dockerfile*", "**/docker-compose*", "**/*.containerfile", "**/charts/**", "**/k8s/**", "**/kubernetes/**", "**/manifests/**"]
 alwaysApply: false
+precedence: high
 ---
 # Container Hardening
 
@@ -46,6 +47,8 @@ Every image carries a CycloneDX 1.6 SBOM, generated at build time and either emb
 
 ## Image Signing — cosign
 
+> Maturity tier: team+ — solo projects with no external consumers may defer signing. Cosign keyless + admission enforcement becomes mandatory once images are pulled by anyone outside the build pipeline.
+
 Every image is signed with cosign keyless mode via OIDC. Sigstore Fulcio issues a short-lived signing certificate scoped to the workflow identity; Rekor records the signature for tamper-evident audit.
 
 - Sign in CI: `cosign sign --yes <registry>/<image>@<digest>`. Workflow grants `id-token: write` permission; no long-lived signing key.
@@ -54,6 +57,8 @@ Every image is signed with cosign keyless mode via OIDC. Sigstore Fulcio issues
 
 ## CVE Scanning in CI
 
+> Maturity tier: team+ — solo projects may run a single scanner ad hoc. Two-scanner CI gating with suppression lifecycle earns its cost once a team owns the release pipeline.
+
 Two scanners are run per image build: `trivy` for breadth (Wolfi advisory database, OS+language deps) and `grype` for Chainguard parity. Release is blocked on unpatched Critical or High CVEs without a documented suppression record.
 
 - `trivy image --severity HIGH,CRITICAL --exit-code 1 <image>:<tag>` fails the job on any High/Critical.
@@ -71,6 +76,8 @@ The same digest-not-tag rule extends beyond `FROM` lines to every place the imag
 
 ## Reproducible Builds
 
+> Maturity tier: scaleup+ — team projects may defer the `repro-build` verification step until a compliance or supply-chain audit requests it. Solo and team projects still pin syntax + package versions; the digest-comparison gate is the scaleup add.
+
 Build inputs are pinned so the same `git checkout` produces the same image digest.
 
 - `# syntax=docker/dockerfile:1.<minor>.<patch>` — pin to a specific BuildKit syntax version.
@@ -105,6 +112,8 @@ Runtime image targets under 200 MB compressed. Builds exceeding 500 MB compresse
 
 ## Verification Gate at Release
 
+> Maturity tier: team+ — solo projects may defer the full five-gate release block. The non-root + digest-pin gates remain mandatory at every tier; cosign verification, dual-scanner thresholds, and SBOM attachment fire once a team owns admission policy.
+
 Every release pipeline executes the following gates before publish, all green:
 
 - `cosign verify` against the workflow OIDC identity.
@@ -113,7 +122,7 @@ Every release pipeline executes the following gates before publish, all green:
 - Pod spec runs as non-root (`runAsNonRoot: true`), read-only root filesystem, dropped capabilities.
 - SBOM attached and downloadable via `cosign download sbom`.
 
-Cross-reference `agents/hatch3r-security-auditor.md` for runtime security audit; `agents/hatch3r-devops.md` for delivery integration; `rules/hatch3r-secrets-management.md` for OIDC trust-policy conditions; `rules/hatch3r-dependency-management.md` for SBOM tooling and SLSA provenance.
+Cross-reference `agents/hatch3r-security.md` (CQ3) for runtime security audit; `agents/hatch3r-devops.md` for delivery integration; `rules/hatch3r-secrets-management.md` for OIDC trust-policy conditions; `rules/hatch3r-dependency-management.md` for SBOM tooling and SLSA provenance.
 
 ## References
 

package/{rules → dist/content/rules}/hatch3r-contract-testing.md

@@ -2,8 +2,10 @@
 id: hatch3r-contract-testing
 type: rule
 description: Consumer-driven and spec-driven contract testing between services — Pact, Schemathesis, Dredd, pact-broker can-i-deploy gate
-scope: "**/contracts/**,**/pacts/**,**/api/**,**/openapi*,**/asyncapi*,**/*.proto,**/__tests__/contract/**"
+scope: conditional
+globs: "**/contracts/**,**/pacts/**,**/api/**,**/openapi*,**/asyncapi*,**/*.proto,**/__tests__/contract/**"
 tags: [review, implementation]
+precedence: high
 quality_charter: agents/shared/quality-charter.md
 cache_friendly: true
 ---

package/{rules → dist/content/rules}/hatch3r-contract-testing.mdc

@@ -2,6 +2,7 @@
 description: Consumer-driven and spec-driven contract testing between services — Pact, Schemathesis, Dredd, pact-broker can-i-deploy gate
 globs: ["**/contracts/**", "**/pacts/**", "**/api/**", "**/openapi*", "**/asyncapi*", "**/*.proto", "**/__tests__/contract/**"]
 alwaysApply: false
+precedence: high
 ---
 # Contract Testing
 

package/dist/content/rules/hatch3r-cost-visibility.md

@@ -0,0 +1,135 @@
+---
+id: hatch3r-cost-visibility
+type: rule
+description: Pre-execution cost estimate + post-execution actuals + delta surfacing in iteration summary. Every orchestrator command emits cost data.
+tags: [cost, telemetry, observability, floor:content-quality]
+precedence: high
+scope: always
+---
+# hatch3r Cost Visibility
+
+**Pillars:** P7 (Speed & Token Efficiency), P5 (Governance Self-Quality)
+
+Source: the cost-visibility design decision and the cost-transparency principle (pillar P7; see `agents/shared/principles.md`).
+
+Every orchestrator command (`commands/hatch3r-*.md` with `orchestrator: true`) and every meaningful skill run that mutates state MUST emit cost data — pre-execution estimate at plan time and post-execution actuals + delta at completion time. The delta lands in the iteration summary's Fan-out + Cost section per `rules/hatch3r-iteration-summary.md` §2.
+
+## Pre-Execution Estimate
+
+Emit at plan time, before fan-out begins:
+
+```yaml
+cost_estimate:
+  expected_sa_count: <int>
+  estimated_input_tokens_static_frame: <int>
+  estimated_web_research_queries: <int>
+  triage_tier: light | standard | deep
+  estimated_duration_min: <int>
+```
+
+Derived from:
+
+- Frontmatter `sub_agents_spawned` declaration when present (static intent declared by the artifact).
+- Triage-tier heuristics: Light = 1-3 SAs, Standard = 4-9 SAs, Deep = 10+ SAs.
+- Past-cycle telemetry baseline from `src/pipeline/observability.ts` — phase-level `inputTokens` + `outputTokens` averaged across recent runs of the same artifact ID.
+- Static-prompt frame character count divided by `CHARS_PER_TOKEN` (default 4) per `src/pipeline/observability.ts::estimateTokens`.
+
+Triage tier maps directly to `triage_tiers` frontmatter declared per Decision 17 (CONSTITUTION §6 Decision #20 in 2.0.0 mapping) — the runtime-selected tier is the one emitted in the estimate block.
+
+## Post-Execution Actuals
+
+Emit at completion time, after the last sub-agent returns:
+
+```yaml
+cost_actuals:
+  actual_sa_count: <int>
+  actual_input_tokens: <int>
+  actual_output_tokens: <int>
+  actual_web_research_queries: <int>
+  actual_duration_min: <float>
+delta:
+  sa_count_delta: <int>
+  input_tokens_delta_percent: <float>
+  duration_delta_percent: <float>
+```
+
+`sa_count_delta` is `actual_sa_count - expected_sa_count` (signed integer). `input_tokens_delta_percent` is `(actual - estimated) / estimated * 100` rounded to one decimal. `duration_delta_percent` follows the same formula on duration.
+
+## Surfacing in Iteration Summary
+
+Per `rules/hatch3r-iteration-summary.md` §2 Fan-out + Cost: both blocks appear in the iteration summary's Cost section. Deltas exceeding 25% (absolute value) flag for review — they signal under- or over-estimation patterns that the next cycle should investigate. The flag is informational, not a gate failure.
+
+A run with no Cost section in its iteration summary fails the iteration-summary validation gate (`.claude/rules/capability-lifecycle.md` Gate Checklist).
+
+### Worked Example
+
+A Tier 2 capability-add run that spawns 5 sub-agents (1 researcher + 4 implementers) emits at plan time:
+
+```yaml
+cost_estimate:
+  expected_sa_count: 5
+  estimated_input_tokens_static_frame: 18000
+  estimated_web_research_queries: 2
+  triage_tier: standard
+  estimated_duration_min: 12
+```
+
+At completion (one extra implementer spawned due to scope expansion discovered mid-run, two extra web queries):
+
+```yaml
+cost_actuals:
+  actual_sa_count: 6
+  actual_input_tokens: 22400
+  actual_output_tokens: 8900
+  actual_web_research_queries: 4
+  actual_duration_min: 15.3
+delta:
+  sa_count_delta: 1
+  input_tokens_delta_percent: 24.4
+  duration_delta_percent: 27.5
+```
+
+`duration_delta_percent` exceeds 25% — flagged informational for next-cycle EVOLVE review. `input_tokens_delta_percent` is 24.4% — under threshold, no flag.
+
+## Source of Telemetry
+
+`src/pipeline/observability.ts` records:
+
+- Input + output tokens per LLM call via `createPhaseTokenEstimate` → `PhaseTokenEstimate`.
+- Per-pipeline aggregation via `createTokenSummary` → `PipelineTokenSummary` (`totalInputTokens`, `totalOutputTokens`, `grandTotal`).
+- Cost estimation via `estimateCost` → `CostEstimate` with `DEFAULT_INPUT_COST_PER_1M = 3.0` USD and `DEFAULT_OUTPUT_COST_PER_1M = 15.0` USD as default rates.
+- Opt-in `EfficiencyEvent` JSONL telemetry via `recordEfficiencyEvent` (env-gated by `HATCH3R_EFFICIENCY_TELEMETRY=1`) — fields: `artifactId`, `phase`, `tokensIn`, `tokensOut`, `latencyMs`, `modelHint?`, `cacheHit?`.
+- Sub-agent spawn count per orchestrator phase (consumed by `rules/hatch3r-agent-orchestration.md` Per-Turn Pipeline-State Header).
+- Web research query count per cycle (incremented by adapter web-research integrations).
+- Duration per phase via phase timeout instrumentation (`src/pipeline/phaseTimeout.ts`).
+
+Implementation contract: `src/pipeline/costEstimator.ts` (to be authored under Bucket 2.3) consumes the baseline from past `EfficiencyEvent` records and emits `cost_estimate`; `src/pipeline/observability.ts` already provides the actuals primitives.
+
+## End-User Visibility
+
+Cost data appears in user-facing iteration summaries by default. Suppressing via the `--quiet` CLI flag still records telemetry to `.hatch3r/telemetry/<session-id>.json` for later review — the channel is preserved per the Silent Failure Contract (P5). Suppression at the user surface does not suppress at the persistence layer.
+
+Telemetry I/O failures route through `src/pipeline/failureLog.ts` per the Silent Failure Contract — never silently swallowed.
+
+## Acceptance Criteria
+
+A change to a `commands/hatch3r-*.md` orchestrator or to a meaningful state-mutating skill satisfies this rule when ALL hold:
+
+1. The artifact emits `cost_estimate` before the first sub-agent spawn.
+2. The artifact emits `cost_actuals` + `delta` before declaring iteration-summary status.
+3. The iteration summary's Fan-out + Cost section (per `rules/hatch3r-iteration-summary.md` §2) carries both blocks.
+4. Telemetry persists to `.hatch3r/telemetry/<session-id>.json` even under `--quiet`.
+5. Delta thresholds beyond 25% absolute value carry an explicit `flagged_for_review: true` annotation in the iteration summary.
+
+## Emission-Rate Telemetry (current status: per-run gate only; cross-run rate not yet wired)
+
+The acceptance criteria above are checked per run. They do NOT measure the cost-block emission rate across runs, and no automated cross-run measurement exists today.
+
+The SPACE-shaped activity/performance instrumentation (`src/pipeline/spaceTelemetry.ts`) provides the recording primitive `recordSpaceMetric`, the in-process aggregator `getSpaceSummary`, and the across-runs reader `loadSpaceMetricsFromDisk`, but they are not invoked on the cost-visibility path: orchestrator commands and skills are LLM-interpreted markdown with no binding to compiled `src/`, and no command, skill, hook, or `src/` code emits a `costVisibilityEmitted` metric. The cross-run emission-rate loop is therefore unwired — a future capability, not a live measurement (origin: D10-SA10.8-F-6; gap corrected D10-18). The module records on the `activity` and `performance` axes only; its `satisfaction` and `communication` axes are reserved with no feeder, so "SPACE" names the data shape, not full five-axis coverage (D10-40).
+
+To wire it, a host-runtime bridge (a Claude Code / Cursor / Copilot post-turn hook or an MCP shim) would need to call `recordSpaceMetric({ metricId: "costVisibilityEmitted", axis: "activity", value: <1 if both cost_estimate and cost_actuals were produced else 0> })` after each orchestrator/meaningful-skill turn, persisting one JSONL line per run to `.hatch3r/telemetry/space-<YYYY-MM-DD>.jsonl`; the audit cycle could then read the persisted JSONL across runs via `loadSpaceMetricsFromDisk` + `summarizeSpaceMetricRecords` (NOT `getSpaceSummary`, which sees only the current process's ring buffer) to check the 100% cost-visibility emission target against observed runs instead of only mandating it. `recordSpaceMetric` already routes I/O failures through `src/pipeline/failureLog.ts` and never throws (Silent Failure Contract), so building the bridge adds no failure surface. Until that bridge ships, cost-visibility compliance is enforced by the per-run acceptance criteria above plus audit-cycle spot checks, not by an aggregate metric.
+
+## Pillar Service
+
+- **P7** — surfaces token + duration measurements to the user; closes the loop on the P7 token-economy goal. Estimation accuracy improves cycle-over-cycle via the past-cycle telemetry baseline.
+- **P5** — every orchestrator measures itself; deltas become first-class governance signals consumed by the governance evolve-cycle.

package/dist/content/rules/hatch3r-cost-visibility.mdc

@@ -0,0 +1,135 @@
+---
+id: hatch3r-cost-visibility
+type: rule
+description: Pre-execution cost estimate + post-execution actuals + delta surfacing in iteration summary. Every orchestrator command emits cost data.
+tags: [cost, telemetry, observability, floor:content-quality]
+precedence: high
+alwaysApply: true
+---
+# hatch3r Cost Visibility
+
+**Pillars:** P7 (Speed & Token Efficiency), P5 (Governance Self-Quality)
+
+Source: the cost-visibility design decision and the cost-transparency principle (pillar P7; see `agents/shared/principles.md`).
+
+Every orchestrator command (`commands/hatch3r-*.md` with `orchestrator: true`) and every meaningful skill run that mutates state MUST emit cost data — pre-execution estimate at plan time and post-execution actuals + delta at completion time. The delta lands in the iteration summary's Fan-out + Cost section per `rules/hatch3r-iteration-summary.md` §2.
+
+## Pre-Execution Estimate
+
+Emit at plan time, before fan-out begins:
+
+```yaml
+cost_estimate:
+  expected_sa_count: <int>
+  estimated_input_tokens_static_frame: <int>
+  estimated_web_research_queries: <int>
+  triage_tier: light | standard | deep
+  estimated_duration_min: <int>
+```
+
+Derived from:
+
+- Frontmatter `sub_agents_spawned` declaration when present (static intent declared by the artifact).
+- Triage-tier heuristics: Light = 1-3 SAs, Standard = 4-9 SAs, Deep = 10+ SAs.
+- Past-cycle telemetry baseline from `src/pipeline/observability.ts` — phase-level `inputTokens` + `outputTokens` averaged across recent runs of the same artifact ID.
+- Static-prompt frame character count divided by `CHARS_PER_TOKEN` (default 4) per `src/pipeline/observability.ts::estimateTokens`.
+
+Triage tier maps directly to `triage_tiers` frontmatter declared per Decision 17 (CONSTITUTION §6 Decision #20 in 2.0.0 mapping) — the runtime-selected tier is the one emitted in the estimate block.
+
+## Post-Execution Actuals
+
+Emit at completion time, after the last sub-agent returns:
+
+```yaml
+cost_actuals:
+  actual_sa_count: <int>
+  actual_input_tokens: <int>
+  actual_output_tokens: <int>
+  actual_web_research_queries: <int>
+  actual_duration_min: <float>
+delta:
+  sa_count_delta: <int>
+  input_tokens_delta_percent: <float>
+  duration_delta_percent: <float>
+```
+
+`sa_count_delta` is `actual_sa_count - expected_sa_count` (signed integer). `input_tokens_delta_percent` is `(actual - estimated) / estimated * 100` rounded to one decimal. `duration_delta_percent` follows the same formula on duration.
+
+## Surfacing in Iteration Summary
+
+Per `rules/hatch3r-iteration-summary.md` §2 Fan-out + Cost: both blocks appear in the iteration summary's Cost section. Deltas exceeding 25% (absolute value) flag for review — they signal under- or over-estimation patterns that the next cycle should investigate. The flag is informational, not a gate failure.
+
+A run with no Cost section in its iteration summary fails the iteration-summary validation gate (`.claude/rules/capability-lifecycle.md` Gate Checklist).
+
+### Worked Example
+
+A Tier 2 capability-add run that spawns 5 sub-agents (1 researcher + 4 implementers) emits at plan time:
+
+```yaml
+cost_estimate:
+  expected_sa_count: 5
+  estimated_input_tokens_static_frame: 18000
+  estimated_web_research_queries: 2
+  triage_tier: standard
+  estimated_duration_min: 12
+```
+
+At completion (one extra implementer spawned due to scope expansion discovered mid-run, two extra web queries):
+
+```yaml
+cost_actuals:
+  actual_sa_count: 6
+  actual_input_tokens: 22400
+  actual_output_tokens: 8900
+  actual_web_research_queries: 4
+  actual_duration_min: 15.3
+delta:
+  sa_count_delta: 1
+  input_tokens_delta_percent: 24.4
+  duration_delta_percent: 27.5
+```
+
+`duration_delta_percent` exceeds 25% — flagged informational for next-cycle EVOLVE review. `input_tokens_delta_percent` is 24.4% — under threshold, no flag.
+
+## Source of Telemetry
+
+`src/pipeline/observability.ts` records:
+
+- Input + output tokens per LLM call via `createPhaseTokenEstimate` → `PhaseTokenEstimate`.
+- Per-pipeline aggregation via `createTokenSummary` → `PipelineTokenSummary` (`totalInputTokens`, `totalOutputTokens`, `grandTotal`).
+- Cost estimation via `estimateCost` → `CostEstimate` with `DEFAULT_INPUT_COST_PER_1M = 3.0` USD and `DEFAULT_OUTPUT_COST_PER_1M = 15.0` USD as default rates.
+- Opt-in `EfficiencyEvent` JSONL telemetry via `recordEfficiencyEvent` (env-gated by `HATCH3R_EFFICIENCY_TELEMETRY=1`) — fields: `artifactId`, `phase`, `tokensIn`, `tokensOut`, `latencyMs`, `modelHint?`, `cacheHit?`.
+- Sub-agent spawn count per orchestrator phase (consumed by `rules/hatch3r-agent-orchestration.md` Per-Turn Pipeline-State Header).
+- Web research query count per cycle (incremented by adapter web-research integrations).
+- Duration per phase via phase timeout instrumentation (`src/pipeline/phaseTimeout.ts`).
+
+Implementation contract: `src/pipeline/costEstimator.ts` (to be authored under Bucket 2.3) consumes the baseline from past `EfficiencyEvent` records and emits `cost_estimate`; `src/pipeline/observability.ts` already provides the actuals primitives.
+
+## End-User Visibility
+
+Cost data appears in user-facing iteration summaries by default. Suppressing via the `--quiet` CLI flag still records telemetry to `.hatch3r/telemetry/<session-id>.json` for later review — the channel is preserved per the Silent Failure Contract (P5). Suppression at the user surface does not suppress at the persistence layer.
+
+Telemetry I/O failures route through `src/pipeline/failureLog.ts` per the Silent Failure Contract — never silently swallowed.
+
+## Acceptance Criteria
+
+A change to a `commands/hatch3r-*.md` orchestrator or to a meaningful state-mutating skill satisfies this rule when ALL hold:
+
+1. The artifact emits `cost_estimate` before the first sub-agent spawn.
+2. The artifact emits `cost_actuals` + `delta` before declaring iteration-summary status.
+3. The iteration summary's Fan-out + Cost section (per `rules/hatch3r-iteration-summary.md` §2) carries both blocks.
+4. Telemetry persists to `.hatch3r/telemetry/<session-id>.json` even under `--quiet`.
+5. Delta thresholds beyond 25% absolute value carry an explicit `flagged_for_review: true` annotation in the iteration summary.
+
+## Emission-Rate Telemetry (current status: per-run gate only; cross-run rate not yet wired)
+
+The acceptance criteria above are checked per run. They do NOT measure the cost-block emission rate across runs, and no automated cross-run measurement exists today.
+
+The SPACE-shaped activity/performance instrumentation (`src/pipeline/spaceTelemetry.ts`) provides the recording primitive `recordSpaceMetric`, the in-process aggregator `getSpaceSummary`, and the across-runs reader `loadSpaceMetricsFromDisk`, but they are not invoked on the cost-visibility path: orchestrator commands and skills are LLM-interpreted markdown with no binding to compiled `src/`, and no command, skill, hook, or `src/` code emits a `costVisibilityEmitted` metric. The cross-run emission-rate loop is therefore unwired — a future capability, not a live measurement (origin: D10-SA10.8-F-6; gap corrected D10-18). The module records on the `activity` and `performance` axes only; its `satisfaction` and `communication` axes are reserved with no feeder, so "SPACE" names the data shape, not full five-axis coverage (D10-40).
+
+To wire it, a host-runtime bridge (a Claude Code / Cursor / Copilot post-turn hook or an MCP shim) would need to call `recordSpaceMetric({ metricId: "costVisibilityEmitted", axis: "activity", value: <1 if both cost_estimate and cost_actuals were produced else 0> })` after each orchestrator/meaningful-skill turn, persisting one JSONL line per run to `.hatch3r/telemetry/space-<YYYY-MM-DD>.jsonl`; the audit cycle could then read the persisted JSONL across runs via `loadSpaceMetricsFromDisk` + `summarizeSpaceMetricRecords` (NOT `getSpaceSummary`, which sees only the current process's ring buffer) to check the 100% cost-visibility emission target against observed runs instead of only mandating it. `recordSpaceMetric` already routes I/O failures through `src/pipeline/failureLog.ts` and never throws (Silent Failure Contract), so building the bridge adds no failure surface. Until that bridge ships, cost-visibility compliance is enforced by the per-run acceptance criteria above plus audit-cycle spot checks, not by an aggregate metric.
+
+## Pillar Service
+
+- **P7** — surfaces token + duration measurements to the user; closes the loop on the P7 token-economy goal. Estimation accuracy improves cycle-over-cycle via the past-cycle telemetry baseline.
+- **P5** — every orchestrator measures itself; deltas become first-class governance signals consumed by the governance evolve-cycle.

package/dist/content/rules/hatch3r-cq-rule-frame.md

@@ -0,0 +1,54 @@
+---
+id: hatch3r-cq-rule-frame
+type: rule
+description: Shared output frame for the CQ measurement rules — the per-finding rigor-field schema and the Specialist-Status to canonical-severity map cited by hatch3r-{security,testability,scalability,maintainability,enhancability}
+scope: conditional
+globs: "src/**,**/__tests__/**,**/handlers/**,**/routes/**,**/services/**,**/api/**,**/migrations/**,**/openapi.yaml,**/openapi.json,**/*.proto,**/schema.graphql,**/asyncapi.yaml"
+tags: [review, floor:content-quality]
+precedence: high
+quality_charter: agents/shared/quality-charter.md
+cache_friendly: true
+---
+# CQ Rule Frame
+
+**Pillars:** P4 (Comprehensive Lean Coverage), P7 (Speed & Token Efficiency)
+
+## Scope
+
+This rule is the single source of two blocks that every CQ measurement rule emits: the per-finding rigor-field schema and the Specialist-Status to canonical-severity map. It is consumed by the CQ vector rules:
+
+- `rules/hatch3r-security.md` (CQ3)
+- `rules/hatch3r-testability.md` (CQ5)
+- `rules/hatch3r-scalability.md` (CQ6)
+- `rules/hatch3r-maintainability.md` (CQ8)
+- `rules/hatch3r-enhancability.md` (CQ9)
+
+Each consuming rule cites this file for both blocks and adds only its rule-specific Action list (the Status-to-Action consequences that differ per CQ vector). The upstream canonical vocabulary owner is `agents/shared/severity-mapping.md` — this file restates only the 3-row Specialist-Status subset that the CQ rules share, parameterized by CQ vector.
+
+## Per-Finding Output Format
+
+Every finding emitted under a CQ measurement rule MUST include the rigor-contract fields per `agents/shared/rigor-contract.md`. `<N>` is the consuming rule's CQ number (3, 5, 6, 8, or 9); the proof-trace artifact named in the first field is the consuming rule's measurement surface (file, test file, handler, or spec diff):
+
+- `proof_trace`: file:line citation + the consuming rule's measurement-output excerpt (command, runner, jscpd/oasdiff/buf-breaking, or spec-diff/grep).
+- `impact_horizon`: short | medium | long per CONSTITUTION Decision 17.
+- `progress_toward_pillar: content-quality.CQ<N>+<delta>`: numeric delta against the threshold (e.g. `+0.05` for a 5% step toward the consuming rule's target).
+- `confidence`: high | medium | low with explicit basis.
+- `causal_chain`: ≥3-step linkage from observation → root cause → impact.
+
+## Specialist-Status to Canonical-Severity Map
+
+Specialist status maps to canonical audit severity per `agents/shared/severity-mapping.md` (the canonical mapping owner). The 3-row subset the CQ rules share:
+
+| Specialist Status | Canonical Severity |
+|-------------------|--------------------|
+| `CRITICAL` | Critical |
+| `FINDINGS` | High + Medium |
+| `PASS` | Low + Info |
+
+The Action column is rule-specific and stays in each consuming rule's Severity Mapping section: the consuming rule lists, per Specialist Status row, the merge/release consequence for its CQ vector (block-release triggers, block-merge triggers, iteration-summary surfacing).
+
+## References
+
+- `agents/shared/severity-mapping.md` (canonical severity-vocabulary owner — 6-column map + Specialist Status column).
+- `agents/shared/rigor-contract.md` (the rigor-field definitions referenced by the output format).
+- `rules/hatch3r-security.md`, `rules/hatch3r-testability.md`, `rules/hatch3r-scalability.md`, `rules/hatch3r-maintainability.md`, `rules/hatch3r-enhancability.md` (the 5 consuming CQ rules).

package/dist/content/rules/hatch3r-cq-rule-frame.mdc

@@ -0,0 +1,49 @@
+---
+description: Shared output frame for the CQ measurement rules — the per-finding rigor-field schema and the Specialist-Status to canonical-severity map cited by hatch3r-{security,testability,scalability,maintainability,enhancability}
+globs: ["src/**", "**/__tests__/**", "**/handlers/**", "**/routes/**", "**/services/**", "**/api/**", "**/migrations/**", "**/openapi.yaml", "**/openapi.json", "**/*.proto", "**/schema.graphql", "**/asyncapi.yaml"]
+alwaysApply: false
+precedence: high
+---
+# CQ Rule Frame
+
+**Pillars:** P4 (Comprehensive Lean Coverage), P7 (Speed & Token Efficiency)
+
+## Scope
+
+This rule is the single source of two blocks that every CQ measurement rule emits: the per-finding rigor-field schema and the Specialist-Status to canonical-severity map. It is consumed by the CQ vector rules:
+
+- `rules/hatch3r-security.md` (CQ3)
+- `rules/hatch3r-testability.md` (CQ5)
+- `rules/hatch3r-scalability.md` (CQ6)
+- `rules/hatch3r-maintainability.md` (CQ8)
+- `rules/hatch3r-enhancability.md` (CQ9)
+
+Each consuming rule cites this file for both blocks and adds only its rule-specific Action list (the Status-to-Action consequences that differ per CQ vector). The upstream canonical vocabulary owner is `agents/shared/severity-mapping.md` — this file restates only the 3-row Specialist-Status subset that the CQ rules share, parameterized by CQ vector.
+
+## Per-Finding Output Format
+
+Every finding emitted under a CQ measurement rule MUST include the rigor-contract fields per `agents/shared/rigor-contract.md`. `<N>` is the consuming rule's CQ number (3, 5, 6, 8, or 9); the proof-trace artifact named in the first field is the consuming rule's measurement surface (file, test file, handler, or spec diff):
+
+- `proof_trace`: file:line citation + the consuming rule's measurement-output excerpt (command, runner, jscpd/oasdiff/buf-breaking, or spec-diff/grep).
+- `impact_horizon`: short | medium | long per CONSTITUTION Decision 17.
+- `progress_toward_pillar: content-quality.CQ<N>+<delta>`: numeric delta against the threshold (e.g. `+0.05` for a 5% step toward the consuming rule's target).
+- `confidence`: high | medium | low with explicit basis.
+- `causal_chain`: ≥3-step linkage from observation → root cause → impact.
+
+## Specialist-Status to Canonical-Severity Map
+
+Specialist status maps to canonical audit severity per `agents/shared/severity-mapping.md` (the canonical mapping owner). The 3-row subset the CQ rules share:
+
+| Specialist Status | Canonical Severity |
+|-------------------|--------------------|
+| `CRITICAL` | Critical |
+| `FINDINGS` | High + Medium |
+| `PASS` | Low + Info |
+
+The Action column is rule-specific and stays in each consuming rule's Severity Mapping section: the consuming rule lists, per Specialist Status row, the merge/release consequence for its CQ vector (block-release triggers, block-merge triggers, iteration-summary surfacing).
+
+## References
+
+- `agents/shared/severity-mapping.md` (canonical severity-vocabulary owner — 6-column map + Specialist Status column).
+- `agents/shared/rigor-contract.md` (the rigor-field definitions referenced by the output format).
+- `rules/hatch3r-security.md`, `rules/hatch3r-testability.md`, `rules/hatch3r-scalability.md`, `rules/hatch3r-maintainability.md`, `rules/hatch3r-enhancability.md` (the 5 consuming CQ rules).

package/{rules → dist/content/rules}/hatch3r-data-classification.md

@@ -2,8 +2,10 @@
 id: hatch3r-data-classification
 type: rule
 description: Data classification standards covering PII handling, encryption, retention policies, and regulatory compliance
-scope: "**/models/**,**/schemas/**,**/schema*,**/database/**,**/db/**,**/*model*,**/*entity*,**/prisma/**,**/drizzle/**,**/*migration*"
-tags: [security]
+scope: conditional
+globs: "**/models/**,**/schemas/**,**/schema*,**/database/**,**/db/**,**/*model*,**/*entity*,**/prisma/**,**/drizzle/**,**/*migration*,**/log*,**/*logger*,**/analytics/**,**/*analytics*,**/events/**,**/*telemetry*,**/export*,**/*export*"
+tags: [floor:security]
+precedence: high
 quality_charter: agents/shared/quality-charter.md
 cache_friendly: true
 ---
@@ -26,6 +28,7 @@ cache_friendly: true
 - Never log PII. Use structured logging with PII fields explicitly excluded or masked.
 - Pseudonymize PII in analytics and reporting. Use irreversible hashing for identifiers.
 - Provide data export and deletion endpoints for data subject requests (GDPR Article 15/17, CCPA).
+- This rule's PII review applies wherever PII can leave the data model — not just schemas and migrations, but log statements, loggers, analytics/telemetry emitters, event payloads, and export paths. Before merging a change to any of these surfaces, confirm no Level 3+ field is logged, emitted, or exported unmasked.
 
 ## Encryption
 

package/{rules → dist/content/rules}/hatch3r-data-classification.mdc

@@ -1,7 +1,8 @@
 ---
 description: Data classification standards covering PII handling, encryption, retention policies, and regulatory compliance
-globs: ["**/models/**", "**/schemas/**", "**/schema*", "**/database/**", "**/db/**", "**/*model*", "**/*entity*", "**/prisma/**", "**/drizzle/**", "**/*migration*"]
+globs: ["**/models/**", "**/schemas/**", "**/schema*", "**/database/**", "**/db/**", "**/*model*", "**/*entity*", "**/prisma/**", "**/drizzle/**", "**/*migration*", "**/log*", "**/*logger*", "**/analytics/**", "**/*analytics*", "**/events/**", "**/*telemetry*", "**/export*", "**/*export*"]
 alwaysApply: false
+precedence: high
 ---
 # Data Classification Standards
 
@@ -22,6 +23,7 @@ alwaysApply: false
 - Never log PII. Use structured logging with PII fields explicitly excluded or masked.
 - Pseudonymize PII in analytics and reporting. Use irreversible hashing for identifiers.
 - Provide data export and deletion endpoints for data subject requests (GDPR Article 15/17, CCPA).
+- This rule's PII review applies wherever PII can leave the data model — not just schemas and migrations, but log statements, loggers, analytics/telemetry emitters, event payloads, and export paths. Before merging a change to any of these surfaces, confirm no Level 3+ field is logged, emitted, or exported unmasked.
 
 ## Encryption
 

package/{rules → dist/content/rules}/hatch3r-deep-context.md

@@ -3,12 +3,15 @@ id: hatch3r-deep-context
 type: rule
 description: Adaptive pre-implementation analysis — complexity scoring, requirements elicitation, similar implementation discovery, and transitive dependency tracing before coding
 scope: always
-tags: [core]
+tags: [orchestration, floor:protocol]
+precedence: high
 quality_charter: agents/shared/quality-charter.md
 cache_friendly: true
 ---
 # Deep Context Analysis
 
+**Pillars:** P2 (Scientific & Practical Quality), P7 (Speed & Token Efficiency)
+
 Before implementing any non-trivial task, assess its complexity and run proportional pre-implementation analysis. This rule ensures the agent asks the right questions, discovers existing patterns to follow, and maps the full blast radius before writing code.
 
 ## Complexity Scoring
@@ -28,11 +31,13 @@ Score every task against these signals before implementation. Each signal adds w
 
 ### Tier Assignment
 
-| Total Weight | Tier | Label |
-|-------------|------|-------|
-| 0–2 | 1 | Light |
-| 3–5 | 2 | Standard |
-| 6+ | 3 | Deep |
+| Total Weight | Tier | Label | Model Class (per-adapter) |
+|-------------|------|-------|---------------------------|
+| 0–2 | 1 | Light | economy |
+| 3–5 | 2 | Standard | default |
+| 6+ | 3 | Deep | strongest |
+
+The **Model Class** column is an abstract effort lever: tier scales the model class the same way it scales researcher depth (`quick`/`deep`) and Phase 4 specialist depth — `economy` for cheap mechanical changes, `default` for routine multi-file work, `strongest` for high-blast-radius reasoning. It is a hint resolved per-adapter against that adapter's model map (`src/models/resolve.ts::resolveAgentModel`, `models.default`), not a literal model id — adapters with no model-routing surface ignore it. Model class is a first-order effort lever alongside depth (`hatch3r-agent-orchestration` -> Tier-to-Phase-4 specialist depth mapping).
 
 ## Tier Actions
 
@@ -93,24 +98,19 @@ This rule augments — not replaces — the existing Universal Sub-Agent Pipelin
 
 ## Scoring Examples
 
-To reduce ambiguity in tier assignment, here are worked examples:
+Worked examples that reconcile signals to a tier (only firing signals listed):
 
 **Example 1: "Fix typo in error message" -- Tier 1 (score 0)**
 No signals triggered. Single file, no cross-module impact, no ambiguity.
 
 **Example 2: "Add email validation to signup form" -- Tier 2 (score 4)**
 - Multiple layers touched (API + UI): +3
-- Estimated 2-3 files: +0
-- Input validation is security-adjacent but not in a security-sensitive area: +0
-- Clear requirements ("validate email format"): +0
 - May trigger cross-cutting i18n for error messages: +1 (partial cross-cutting)
+- 2-3 files, clear requirements, input validation not in a security-sensitive area: +0 each
 
 **Example 3: "Migrate auth from session-based to JWT" -- Tier 3 (score 12)**
 - Multiple layers (auth middleware + API + UI + storage): +3
-- Vague term "migrate" (scope unclear): +2
-- Cross-cutting auth concern: +2
-- Security-sensitive area: +2
-- Behavioral contract change (session API to JWT API): +2
+- Vague term "migrate", cross-cutting auth, security-sensitive area, behavioral contract change (session API to JWT API): +2 each
 - Estimated >5 files: +1 (partial -- easily >5)
 
 When a signal partially applies (e.g., "maybe 5 files, maybe 4"), round down. Tier upgrades from adaptation (see `hatch3r-agent-orchestration-detail`) compensate for underestimates.