kenaz 0.3.22 → 0.3.23

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

@@ -1,322 +0,0 @@
-# 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

@@ -1,227 +0,0 @@
-# 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.