kenaz 0.0.0-stage → 0.3.2

package/core/dev/archive/ansuz/designs/check_guard.md

@@ -0,0 +1,322 @@
+# synapse_check_guard design
+
+## Goal
+
+Add a Phase 3 pre-dispatch redundancy guard that checks whether a proposed task is materially similar to archived work or an already-recorded decision before Ansuz creates a new task card or dispatches execution.
+
+This is a direct countermeasure for B-002: task-title-driven hallucination caused by selective pulsing. The guard must warn on likely redundancy, surface the overlap to the user, and require explicit override for risky duplicates.
+
+## MCP contract
+
+`synapse_check_guard(title, description, threshold?) -> GuardResult`
+
+### Inputs
+
+- `title: string`
+- `description: string`
+- `threshold?: number`
+
+`threshold` is an optional tuning knob for operators, but verdicts still use the fixed product thresholds below:
+
+- `hard_warn` when combined similarity `>= 0.80`
+- `soft_warn` when combined similarity `>= 0.60` and `< 0.80`
+- `clear` when combined similarity `< 0.60`
+
+### Output schema
+
+```json
+{
+  "similar_tasks": [
+    {
+      "task_id": "TASK_000",
+      "title": "Existing archived task",
+      "status": "done|cancel|archived",
+      "score": 0.84,
+      "score_breakdown": {
+        "fts_title": 0.82,
+        "embedding_task": 0.87
+      },
+      "matched_fields": ["title", "description"],
+      "why": "Short explanation of overlap"
+    }
+  ],
+  "similar_decisions": [
+    {
+      "source": "cortex_recall",
+      "rune_id": "optional-rune-id",
+      "project": "KenazAI",
+      "summary": "Decision summary",
+      "score": 0.79,
+      "why": "Decision already covers the same intent"
+    }
+  ],
+  "verdict": "clear|soft_warn|hard_warn",
+  "rationale": "Human-readable summary of the strongest overlaps and why the verdict fired"
+}
+```
+
+The `similar_tasks` array must never be omitted. If nothing relevant is found, return `[]`. The same applies to `similar_decisions`.
+
+## Corpus and retrieval
+
+The design intentionally reuses existing infrastructure. Do not introduce a new full-text engine.
+
+### Task corpus
+
+Search against task records in `done`, `cancel`, and archived history. The simplest source is `task-api.js list` filtered to completed or abandoned states, then normalized into a candidate corpus of:
+
+- `task_id`
+- `title`
+- `description`
+- `status`
+- optional tags or scope metadata when available
+
+### Decision corpus
+
+Search existing decisions through `cortex_recall` with `type=decision`. This keeps the guard aligned with preserved architectural intent, including cross-project decisions that may already answer the current proposal.
+
+## Scoring algorithm
+
+Use a fused similarity score with three channels.
+
+### 1. FTS5 title search
+
+Run an FTS5-style title search over archived, cancelled, and done task titles.
+
+Recommended normalization:
+
+- lowercase
+- trim punctuation
+- split on whitespace, dash, slash, underscore
+- remove low-signal stopwords such as `task`, `phase`, `fix`, `add` only if they dominate the query
+
+Produce `fts_title` in `[0, 1]` using normalized rank. A practical mapping is:
+
+- exact or near-exact title hit: `0.90-1.00`
+- same noun phrase with minor rewording: `0.70-0.89`
+- weak lexical overlap: `0.30-0.69`
+- no useful match: `0.00`
+
+This stage is fast and catches obvious duplicates, but it is not sufficient alone.
+
+### 2. Embedding similarity for archived tasks
+
+Embed the proposed `title + "\n" + description` and compare against archived task `title + "\n" + description`.
+
+Produce `embedding_task` in `[0, 1]`. This catches semantic duplicates where titles differ but the implementation intent is the same.
+
+Candidate pruning:
+
+- first take top lexical candidates from the FTS pass
+- optionally include a recent archived sample window when no FTS hits exist
+- compute embeddings only for the narrowed candidate set to keep latency bounded
+
+### 3. Decision recall similarity
+
+Call `cortex_recall` with a decision-focused query built from the proposed title and description. Score the returned decision runes as `decision_similarity` in `[0, 1]`.
+
+Interpretation:
+
+- a high score means "this work may already be settled as a decision"
+- decision matches should elevate caution even if no archived task title is close
+
+## Score fusion
+
+Compute per-task and per-decision candidates separately, then derive a single guard score.
+
+### Per-task score
+
+```text
+task_score = max(fts_title, embedding_task)
+```
+
+Reasoning: lexical and semantic overlap are both valid duplicate signals. A strong hit in either channel should survive.
+
+### Decision score
+
+```text
+decision_score = decision_similarity
+```
+
+### Final combined score
+
+```text
+combined_score = max(
+  strongest_task_score,
+  strongest_decision_score
+)
+```
+
+This is intentionally conservative. The guard exists to catch redundant work, so the strongest credible overlap should determine the verdict.
+
+## Verdict thresholds
+
+These values are product rules, not suggestions:
+
+- `combined_score >= 0.80` -> `hard_warn`
+- `combined_score >= 0.60 && combined_score < 0.80` -> `soft_warn`
+- `combined_score < 0.60` -> `clear`
+
+`threshold` may adjust retrieval breadth or display filtering, but it must not silently change the `0.80 / 0.60` verdict boundaries without a separate product decision.
+
+## phase_3 integration point
+
+Insert the guard in `phase_3` after the task table is finalized and before any `task-api.js create` call or downstream dispatch.
+
+Required sequence:
+
+1. Ansuz finishes task shaping and has final `title` and `description`.
+2. Ansuz calls `synapse_check_guard(title, description, threshold?)`.
+3. If `verdict=clear`, proceed silently to `task-api.js create`.
+4. If `verdict=soft_warn` or `verdict=hard_warn`, stop before creation and surface an AskUserQuestion override prompt.
+5. Only create the task after the user explicitly confirms an override or chooses to revise the proposal.
+
+This makes the guard a pre-creation gate, not a post-hoc lint.
+
+## Phase 3 Integration Anchor
+
+The exact insertion anchor in `.specialist/Ansuz/legacy/phases/phase_3.yaml` is inside the top-level `actions` list at lines `170-176`.
+
+- `actions[5]` at line `175`: `phantom_declaration`
+- `actions[6]` at line `176`: `cgdd_contract_analysis`
+- next top-level block at line `213`: `interaction`, which is the AskUserQuestion approval gate
+
+That means `synapse_check_guard` slots in after the existing design-shaping steps and before user approval:
+
+```yaml
+actions:
+  - "..."
+  - "..."
+  - "..."
+  - "..."
+  - "Run phantom_declaration ..."
+  - "Run cgdd_contract_analysis ..."
+  - "Run synapse_check_guard(title, description, threshold?) and attach guard result to Phase 3 output"
+
+interaction:
+  type: ask
+```
+
+Operationally, the anchor is:
+
+1. finish `phantom_declaration`
+2. finish `cgdd_contract_analysis`
+3. run `synapse_check_guard`
+4. if the verdict is `soft_warn` or `hard_warn`, surface that result in the existing `interaction` AskUserQuestion step
+5. only proceed to `task-api.js create` after the user approves or revises
+
+This is deliberately before the approval prompt, not after it. The point is to let the user evaluate redundancy evidence in the same approval step that already gates Phase 3 output.
+
+## Delineation from synapse_rune_conflicts
+
+`synapse_check_guard` and `synapse_rune_conflicts` are complementary, not overlapping.
+
+- `synapse_check_guard` targets proposed task titles and descriptions. It searches the archived task corpus (`done`, `cancel`, archived history) with FTS5-style title matching plus task-level embedding similarity, then supplements that with decision recall.
+- `synapse_rune_conflicts` targets rune-level contradictions. It analyzes existing runes for semantic conflict using embedding similarity and its three-layer conflict detection logic.
+
+They answer different questions:
+
+- `synapse_check_guard`: "Are we about to create work that already exists, was already attempted, or was already decided?"
+- `synapse_rune_conflicts`: "Do the knowledge artifacts we already recorded contradict each other?"
+
+Both can fire on the same input, but they do so for different reasons:
+
+- a new task proposal may match an archived task title even if no rune conflict exists
+- a new task proposal may also touch a symbol whose runes disagree, which is a separate knowledge-quality problem
+
+There is no functional overlap between them. `synapse_check_guard` is a pre-creation redundancy gate over task corpus plus decision corpus; `synapse_rune_conflicts` is a cognitive consistency check over rune memory.
+
+## override flow
+
+When the guard returns `soft_warn` or `hard_warn`, AskUserQuestion must show:
+
+- the proposed title
+- the top `similar_tasks`
+- the top `similar_decisions`
+- the `rationale`
+- the severity level
+
+Recommended options:
+
+- `Revise title/description`
+- `Open existing task or decision`
+- `Proceed with override`
+- `Cancel`
+
+### soft_warn behavior
+
+- default choice should bias toward review, not override
+- allow `Proceed with override` in a single confirmation step
+- record that the task was created with `override=true` and the selected conflicting item ids
+
+### hard_warn behavior
+
+- block automatic creation by default
+- require explicit user override
+- require a short justification before continuing
+- persist override metadata with the created task or dispatch note
+
+Example override payload:
+
+```json
+{
+  "override": true,
+  "override_reason": "Different scope despite similar archive title",
+  "guard_verdict": "hard_warn",
+  "conflict_refs": ["TASK_412", "decision:rune_abc"]
+}
+```
+
+## fail-open behavior
+
+Infrastructure failure must never block task creation.
+
+If the MCP call is unavailable, times out, or returns malformed data:
+
+- emit a warning in the Phase 3 output
+- mark the guard status as unavailable
+- proceed to `task-api.js create`
+- do not synthesize a fake `soft_warn` or `hard_warn`
+
+This is fail-open on infrastructure, fail-closed on actual overlap.
+
+## Ranking and display rules
+
+- Return at most 5 `similar_tasks`, ordered by `score desc`.
+- Return at most 5 `similar_decisions`, ordered by `score desc`.
+- Prefer explainable results over large result sets.
+- `rationale` should summarize the single strongest task overlap and the single strongest decision overlap when present.
+
+## Edge cases
+
+### Repeated implementation with different target scope
+
+If the title is similar but scope paths or target subsystem differ, the score may still be high. This is why override remains available.
+
+### Existing decision but no archived task
+
+If `similar_decisions` is strong and `similar_tasks` is empty, the guard should still fire. A repeated design decision can be redundant even when no previous execution task exists.
+
+### Empty description
+
+If description is blank, run the guard on title only, but lower confidence in semantic matching. This should bias toward weaker evidence, not toward silence.
+
+## Minimal implementation shape
+
+Suggested server-side flow:
+
+1. collect completed-task corpus from existing task APIs
+2. run FTS title pass
+3. run embedding comparison on narrowed task candidates
+4. run `cortex_recall` for decisions
+5. fuse scores
+6. return `similar_tasks`, `similar_decisions`, `verdict`, `rationale`
+
+## Acceptance hooks
+
+The design intentionally includes the exact anchors required for verification:
+
+- `similar_tasks`
+- `threshold`
+- `phase_3`
+- `override`

package/core/dev/archive/ansuz/designs/consequence_loop.md

@@ -0,0 +1,227 @@
+# Consequence Loop — Design
+
+**Author**: Ansuz (session 2026-04-22, branch xyz951610)
+**Status**: Draft (Phase 6 approval pending)
+**Motivation**: Close the learning gap between "task completed" and "decision was actually good". Currently reflex_neurons learn from single-turn reward (tool proportions, mirror match) but never from downstream consequence (re-open, incident, user correction, health regression).
+
+## Design principles
+
+1. **Explicit temporal layers**: immediate (this turn) / near (this session) / medium (this week) / long (this month). Each tier has its own signal sources and its own learning rate.
+2. **Attribution primitive = scope_paths**: use the already-existing task scope intersection as the credit-assignment proxy. Attribute consequences to the symbols/files the task touched.
+3. **Learning intensity decays with horizon + requires accumulated evidence**: a single 1-month-late signal cannot flip a reflex decision alone. Requires N≥3 consistent signals to trigger rule proposals.
+4. **Governance tiered by reversibility**: weight updates automatic (reversible via audit log); rule proposals require Phase 6 human approval; immutable_core is never writable via consequence feedback.
+5. **Audit + rollback**: every update has `signal_source_id`, `timestamp`, and a reversal command recorded.
+
+## Signal inventory (ranked by signal-to-noise)
+
+| Rank | Signal | Source | Horizon | Noise | MVP Phase |
+|:----:|--------|--------|---------|-------|:---------:|
+| 1 | Task re-opened (done → blocked/active) | task-api state change | days | low | **I** |
+| 2 | FIX-followup task created referencing root task | task-api + tag/description scan | days | low-med | **I** |
+| 3 | `.failure/FAIL-xxx` references a task or symbol | file scan | days-weeks | low | **II** |
+| 4 | Heimdall health drop 7d after merge | Heimdall trend query | days | medium | **II** |
+| 5 | User correction in transcript mentions specific symbol/file | muninn extraction | immediate-days | medium | **III** |
+| 6 | Rune confidence decay — a cited rune later proven wrong | rune validation failure | weeks | low | **III** |
+| 7 | Test / benchmark regression | CI results | hours-days | low | **IV** (needs CI integration) |
+| 8 | User-stated dissatisfaction via sentiment | transcript analysis | immediate | high | **IV** (needs sentiment pipeline) |
+
+## Architecture
+
+```
+┌─────────────────────────────────────────────┐
+│ Consequence Signal Extractor (daemon/cron)  │
+│  ├── task_reopen_detector.js                │
+│  ├── fix_followup_detector.js               │
+│  ├── incident_attribution.js                │
+│  ├── heimdall_delta.js                      │
+│  └── user_correction_extractor.js           │
+└────────────────┬────────────────────────────┘
+                 │ JSONL records
+                 ▼
+  .kenaz/specialist/consequence_signals.jsonl
+  Record schema (per line):
+  {
+    "ts":                ISO-8601,
+    "signal_id":         "cs-{uuid}",
+    "signal_type":       "task_reopen" | "fix_followup" | ...,
+    "root_task_id":      "TASK_XXXX",
+    "affected_symbols":  [stable_id, ...],
+    "scope_paths":       [file_path, ...],
+    "severity":          "low" | "medium" | "high",
+    "confidence":        0.0–1.0,
+    "credit_share":      0.0–1.0,   // for multi-cause attribution
+    "evidence":          { ... signal-specific payload ... }
+  }
+                 │
+                 ▼
+┌─────────────────────────────────────────────┐
+│ Consequence Router                           │
+│  ├── → reflex_neurons STDP (α_consequence=0.01)│
+│  ├── → rune confidence decay                │
+│  ├── → self-model blind_spot evidence append│
+│  └── → rule proposal draft (if N≥3 match)   │
+└────────────────┬────────────────────────────┘
+                 │
+                 ▼
+┌─────────────────────────────────────────────┐
+│ Governance Layer                             │
+│  ├── Rule proposal → Phase 6 human approval  │
+│  ├── Outcome-rate tracking per change        │
+│  └── Reversal index (rollback command)       │
+└─────────────────────────────────────────────┘
+```
+
+## Phased roadmap
+
+### Phase I — Vertical slice (2 weeks)
+**Goal**: Prove the loop wire works. Do NOT aim for coverage.
+
+- Build `task_reopen_detector.js` + `fix_followup_detector.js`
+- Emit to `.kenaz/specialist/consequence_signals.jsonl`
+- Route to `reflex_neurons` with small STDP delta (α=0.01 * severity)
+- **Validation metric**: reflex weight distribution `{min, max, stdev}` measured weekly; compare to Phase 0 baseline (`min=-0.03, max=0.10, stdev~0.02`)
+- **Success criterion**: after 4 weeks of signals, weight range expands to ≥ 0.25 (currently 0.13)
+
+### Phase II — Heimdall long-horizon signal (2–3 weeks)
+- `heimdall_delta.js`: compare health at merge vs 7d later; degrade → signal attributed to merged task scope_paths
+- New signal_type `heimdall_regression`
+- Also: `incident_attribution.js` — scan `.failure/FAIL-xxx` for task references, emit retroactively
+- **Validation**: can the extractor auto-attribute known past regressions (from `.failure/` ground truth)?
+
+### Phase III — Self-model + rule feedback (2–3 weeks)
+- Consequence pattern N≥3 matches → generate draft rule proposal (written to `ansuz_rules.yaml` as `status: proposed`)
+- blind_spot evidence append (reflex of B-00X gets new evidence entry with signal_source_id)
+- **Validation**: ≥1 auto-generated rule proposal reviewed by human; quality judged acceptable
+
+### Phase IV — User correction + complex signals (1 month+)
+- muninn `user_observations` feed → correction trend extraction per domain
+- Rune confidence decay (rune referenced but later contradicted)
+- **Validation**: quantifiable reduction in specialist error rate on specific task classes
+
+## Governance rules
+
+- ❌ Consequence-driven updates **cannot** modify `immutable_core` (identity, principles, phase_sequence, AskUserQuestion mandate, MEM-LANG-001, CANARY protocol)
+- ✅ Consequence-driven weight updates on `reflex_neurons` are **automatic** (reversible via audit log)
+- ⚠️ Consequence-driven **rule proposals require Phase 6 human approval** before merging into `ansuz_rules.yaml`
+- ✅ Every update records: `{signal_id, source_signal_type, ts, prior_value, new_value, rollback_cmd}`
+
+## Risk inventory
+
+| ID | Risk | Mitigation |
+|----|------|------------|
+| R1 | **Noise cascade** — bad signal → wrong attribution → wrong weight → worse behavior | Small α=0.01 per-signal; N≥3 consistent pattern before rule promotion |
+| R2 | **Wrong credit assignment** — attributing downstream bug to unrelated task | Use scope_paths intersection strictly; empty intersection → drop signal |
+| R3 | **Survivorship bias** — only `done` tasks get signals; `cancel`/`blocked` are dark | Track cancelled tasks with reason (duplicate/wrong-spec/infeasible); feed into rule-quality signal |
+| R4 | **Feedback-loop divergence** — reflex discourages a tool → no samples → no learning → permanent dead zone | ε-greedy override: force-sample discouraged tools at 5% probability; flag neurons with 0 updates >30d |
+| R5 | **Hypothesis-efficiency bloat (B-008 class)** — each signal tests one hypothesis, wasting information | Multi-signal extractor design: each detector must list the hypotheses it discriminates |
+| R6 | **Gaming via Goodhart's Law** — agent learns to avoid tracked patterns without solving underlying issue | Rotate validation metrics; don't let reflex directly see the consequence_signals.jsonl as input |
+
+## Interface with existing systems
+
+### Reusing (no new build)
+- `.kenaz/specialist/turn_feedback.jsonl` schema
+- `reflex_executor.js` STDP path (existing `apply_stdp` in reflex_neurons.rs)
+- `ansuz_rules.yaml` versioning + lifecycle
+- `ritual_log` for audit trail
+- `.failure/*.yaml` format
+
+### Extending
+- task-api: need lifecycle event emitter (state-change hook) — event `{task_id, from_status, to_status, ts}`
+- Heimdall: need 7d-lookback health query endpoint
+- muninn: user_observations.jsonl already has correction trend, needs per-symbol attribution extraction
+
+## Resolved decisions (approved 2026-04-22)
+
+### D1. α_consequence — severity-weighted, narrow range
+
+```
+base_α = 0.01
+multiplier = clamp((fix_followup_count + age_weeks + scope_size/3) / 5, 0.5, 3.0)
+  where age_weeks = floor(age_days / 7)
+effective_α = base_α × multiplier
+           → effective_α ∈ [0.005, 0.03]
+```
+
+Rationale: flat-0.01 loses signal differentiation; 10× range [0.005, 0.05] compounds noise. 6× range is the calibration sweet spot. **Severity MUST be derived from objective task attributes** (fix-followup count, age-in-weeks of re-open, regression file count) — never human-labeled severity, which would re-introduce the bias the loop is meant to reduce.
+
+**Calibration check** (against Amelia S3 audit 2026-04-22):
+- Minimal case (fix=1, age=0w, scope=1): numerator = `(1 + 0 + 0.33)/5 = 0.27` → clamped to floor 0.5 → α = 0.005
+- Mid case (fix=3, age=3w, scope=15): numerator = `(3 + 3 + 5)/5 = 2.2` → α = 0.022 (uses middle of band)
+- Extreme (fix=5, age=8w, scope=30): numerator = `(5 + 8 + 10)/5 = 4.6` → clamped to 3.0 → α = 0.030
+
+Earlier draft used `/3` denominator which saturated mid-range inputs to ceiling. `/5` preserves dynamic range.
+
+### D2. Attribution — staged (flat for Phase I, distance-weighted from Phase II)
+
+**Phase I**: flat attribution over `scope_paths` symbols. Rationale: Phase I signals (task_reopen, fix_followup) usually have narrow scope (<5 files); flat is accurate enough and keeps MVP lean.
+
+**Phase II+**: distance-weighted attribution using `delta_graph` data:
+
+```
+symbol directly in commit diff              → 1.0
+symbol reached via delta_graph (1-hop)      → 0.5
+symbol in same file, not touched            → 0.2
+symbol in broader scope_paths, no diff      → 0.1
+```
+
+Rejected: tonic-weighted attribution. Would create feedback-loop divergence (tonic → more updates → more tonic) — matches Risk R4 amplification pattern.
+
+### D3. Signal decay — dual half-life
+
+```
+propagation_half_life = 30 days    (governs weight-update strength)
+retention_half_life   = 180 days   (governs pattern-N evidence count)
+```
+
+Rationale: single half-life cannot simultaneously satisfy "old signals shouldn't move current weights much" AND "old signals should still count as evidence for pattern accumulation". Two clocks decouple action-horizon from learning-horizon. Consistent with Synapse/Thalamus precedent (Heat 12h, Tonic 30d — different purposes, different clocks).
+
+### D4. Rule-proposal language — English
+
+All consequence-driven rule drafts, signal types, and audit-log entries are written in English. Matches existing `ansuz_rules.yaml` / `kernel.yaml` / preamble / Turn Context convention. Chinese examples allowed inside rule bodies where referencing Chinese-specific user patterns, but the rule frame (`rule:`, `reason:`, `how_to_apply:`) is English.
+
+### D5. Signal opacity — Path B (opaque to LLM)
+
+**`consequence_signals.jsonl` is NOT injected into the Ansuz preamble or Turn Context.** The signal flow is:
+
+```
+Extractor → signals.jsonl → Router → { reflex_weights, rule_proposals, audit_log }
+                                          │
+                                          ▼
+                                  LLM observes only *behavior*
+                                  (weight-shifted reflex, new rules
+                                   after Phase 6 approval)
+```
+
+Rationale: if the LLM sees raw consequence signals, it may game tracked patterns (Goodhart's-law variant) — avoid the behavior that gets flagged without solving the underlying issue. Opacity forces learning to happen at the sub-symbolic weight-update level, closer to habit formation than to deliberate reflection. If future evidence shows Path B underperforms, Path A (transparent) can be layered on as an opt-in "conscious reflection" mode; we do not default to it.
+
+**Operational implication**: `preamble.rs` must NOT read from `consequence_signals.jsonl`. Reflex_neurons may read it to update weights. Self-evolution framework may read it to draft rule proposals. That's the closed set of consumers.
+
+## Next step
+
+If this design is approved, create **TASK_13XX [CONSEQUENCE-I] Phase I vertical slice** with scope:
+- `.formation/consequence/task_reopen_detector.js` (new)
+- `.formation/consequence/fix_followup_detector.js` (new)
+- `.formation/consequence/consequence_router.js` (new)
+- `.kenaz/specialist/consequence_signals.jsonl` (new, runtime-written)
+- `dashboard/src-tauri/src/features/synapse/reflex_neurons.rs` (extend to accept consequence-signal feedback)
+
+Estimated: ~8-12 hrs for Phase I MVP.
+
+## APPROVAL
+
+- **Status**: APPROVED
+- **Signer**: Ansuz (session 2026-04-22, branch xyz951610, phase-gate Phase 6)
+- **Timestamp**: 2026-04-22T07:15:00+08:00
+- **Verdict**: ratify D1–D5 as-written; no revisions required
+- **Decisions ratified**:
+  - D1 (severity-weighted α) — ratified. Amelia S3 /5-denominator revision preserves dynamic range; calibration across minimal/mid/extreme cases verified.
+  - D2 (staged attribution) — ratified. Flat for Phase I is accurate for narrow-scope signals; distance-weighted for Phase II correctly uses delta_graph 1-hop. Tonic rejection is the right guard against R4 feedback-loop divergence.
+  - D3 (dual half-life 30d/180d) — ratified. Decoupling action-horizon (weight decay) from learning-horizon (pattern evidence) is the correct primitive; matches Synapse/Thalamus precedent of multi-clock design.
+  - D4 (English rule frame) — ratified. Alignment with MEM-LANG-001 and FTS5 is non-negotiable; Chinese allowed inside rule bodies where the pattern itself is Chinese-specific.
+  - D5 (Path B opacity) — ratified. Highest-stakes call. Goodhart's-law avoidance outweighs transparency-for-debugging because Path A→B is training-data-biased-permanent while Path B→A is reversible. Phase I success metric (weight-range expansion ≥0.25) is independent of raw signal visibility, so the meta-signal for "is Path B working?" is preserved without opening the opacity gate.
+- **TASK_1367 alignment**: confirmed. AC #4 opacity grep encodes D5; AC #3 severity formula encodes D1; AC #6 flat attribution test encodes D2-phase-I; signal schema in req #7 encodes D4; per-call ±0.05 weight clamp in req #5 reflects Amelia S2 audit.
+- **Unblocks**: TASK_1367 can be dispatched as Phase I vertical slice without further design review.
+- **Downstream watch-points** (not blockers, but worth noting for Phase II/III planners):
+  - R3 survivorship bias (cancelled-task signal) is correctly out-of-scope for Phase I but should surface in Phase II planning.
+  - R4 ε-greedy 5% override is not in Phase I scope — neurons that accumulate negative weight could enter dead zones before Phase II ships. Acceptable for MVP given 4-week Phase I window, but monitor reflex_neurons weight distribution monthly.
+  - D5 opacity assumes outcome_rate (from self-evolution framework) gives enough meta-signal for "is the loop learning the right things?" — if outcome_rate itself becomes gameable, a Path-B/Path-A debate will need to re-open. Not a Phase I concern.