Explorar el Código

Add OpenSpec change pack for RC1 governed optimization

erwin hace 1 mes
padre
commit
c2c7c92c65

+ 7 - 0
research/dragon/v2/MEMORY.md

@@ -1046,3 +1046,10 @@
 - Improved test portability:
 - `tests/test_reason_catalog_mapping.py` now derives trade reasons directly from strategy output (snapshot + engine) instead of relying on `dragon_historical_trade_details.csv`.
 - this removes a local-cache dependency and keeps tests runnable in cleaner environments.
+- Added a fresh optimization proposal document for the next execution stage:
+- `dragon_v2_rc1_optimization_proposal_cn.md`
+- proposal scope focuses on phase-3+ execution: rule-engine split (`core/secondary/bridge`), structured state migration away from reason-string control coupling, weak-family optimization in a new branch with attribution-first acceptance, and stronger no-silent-path-change testing.
+- User explicitly requested to推进 in OpenSpec form.
+- Added local OpenSpec governance package under `dragon/v2`:
+- `openspec/config.yaml`
+- change set `openspec/changes/rc1-layered-governed-optimization/` with proposal/design/tasks/spec docs covering layered rule-engine migration, structured state migration, weak-family governance, and golden regression gates.

+ 4 - 0
research/dragon/v2/USER.md

@@ -19,3 +19,7 @@
 - User preference: before switching Codex CLI/session surfaces, record important completed changes explicitly in workspace memory so follow-up work can resume without losing context.
 - User preference: memory files in this workspace must also be committed to git, otherwise important context may be lost across sessions.
 - User instruction: useful code changes can be committed directly without asking again.
+- User preference: when requesting external consultation/review, prepare a compact zip bundle with issue summary, core source, parameter snapshots, and key evidence reports.
+- User preference: live signal checks should support intraday realtime evaluation, using the current market price as the provisional `close` for today's bar when the official daily bar is not yet available.
+- User relies on the assistant for directional judgment when a live signal looks discretionary or when it is unclear whether a veto is filtering alpha or protecting quality; answers should be explicit rather than hedged.
+- User preference: strategy-governance and optimization execution should be advanced in OpenSpec form (`openspec/changes/...`) for traceable proposal/design/tasks/spec workflow.

+ 16 - 0
research/dragon/v2/memory/2026-04-09.md

@@ -26,3 +26,19 @@
 - `tests/test_reason_catalog_mapping.py` no longer depends on local `dragon_historical_trade_details.csv`.
 - It now uses `_load_indicator_snapshot(...)` + `DragonRuleEngine.run(...)` to derive release-window reasons directly from strategy output.
 - Re-ran tests after this change: all `3` tests still pass.
+- Added a next-stage optimization proposal for execution:
+- file: `dragon_v2_rc1_optimization_proposal_cn.md`
+- focus: phase-3+ plan with `core/secondary/bridge` execution split, reason-string decoupling, weak-family optimization in new branch, and stronger regression/reporting acceptance gates.
+- User requested to proceed in OpenSpec format.
+- Added `openspec/` structure for `dragon/v2`:
+- `openspec/config.yaml`
+- change package `openspec/changes/rc1-layered-governed-optimization/` with:
+- `.openspec.yaml`
+- `proposal.md`
+- `design.md`
+- `tasks.md`
+- `specs/layered-rule-engine/spec.md`
+- `specs/structured-decision-state/spec.md`
+- `specs/weak-family-research-governance/spec.md`
+- `specs/golden-regression-governance/spec.md`
+- Updated `USER.md` to persist preference: future optimization/governance推进 should use OpenSpec workflow.

+ 2 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09

+ 67 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/design.md

@@ -0,0 +1,67 @@
+## Context
+
+Current `dragon/v2` governance baseline is already in place:
+
+- RC1 frozen policy is documented.
+- Structured reason typing and catalog exist.
+- Golden baseline and core hash manifest are generated.
+- Layer attribution and baseline regression tests are executable.
+
+The next stage must improve change safety and optimization control without destabilizing RC1.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Create an execution architecture that isolates `core`, `secondary`, and `bridge` decision layers.
+- Replace internal control dependence on reason-string prefixes with structured state fields.
+- Keep RC1 compatibility path intact while enabling branch-only weak-family experiments.
+- Strengthen acceptance gates so behavior-preserving refactors are provably stable.
+
+**Non-Goals:**
+- Retune RC1 thresholds in-place.
+- Perform a one-shot rewrite that bypasses compatibility checks.
+- Promote new weak-family variants without attribution and stress validation.
+
+## Decisions
+
+### 1. Compatibility-first layered split
+
+Layer modules will be introduced first, while `dragon_strategy.py` remains a compatibility facade. The facade keeps downstream interfaces stable and allows phased migration without blocking daily reporting.
+
+### 2. Structured state migration in two passes
+
+Pass 1 keeps output compatibility and adds structured decision metadata (already done).  
+Pass 2 migrates internal control logic from reason-string checks to explicit structured context fields.
+
+### 3. Weak-family optimization is branch-isolated
+
+`deep_oversold_*`, `predictive_*`, and `post_sell_rebound_*` optimization is performed only in dedicated research branches. Every experiment must ship added/removed trade attribution versus RC1 baseline.
+
+### 4. Guardrails before behavior expansion
+
+No behavior-changing experiment is accepted until golden hash regression, release-window summaries, and signal-pipeline smoke checks all pass.
+
+## Risks / Trade-offs
+
+- [Layer split may change evaluation order] -> Preserve legacy orchestration order in compatibility mode and verify by golden hash.
+- [Hybrid string + structured control can drift] -> Ban new string-prefix control logic and migrate high-risk paths first (`predictive_*`, pending chains).
+- [Weak-family tuning may reintroduce overfitting] -> Require attribution-first evidence and execution-stress checks before acceptance.
+
+## Migration Plan
+
+1. Introduce `openspec` governance package and change set for phase-3 optimization.
+2. Add layered execution modules with compatibility wrapper; keep behavior stable.
+3. Migrate internal control paths from string-based checks to structured state.
+4. Enable weak-family branch experiments with mandatory attribution outputs.
+5. Expand tests for no-silent-path-change, bridge chain regression, and weak-family path replay.
+
+## Rollback Plan
+
+- If compatibility migration fails any golden gate, revert to previous passing commit.
+- If branch experiment degrades attribution-quality gates, archive branch as negative evidence and keep RC1 unchanged.
+
+## Open Questions
+
+- Should bridge-layer extraction happen as one move or by family (`predictive_*` first)?
+- Which weak-family subtype should receive the first confirmation-gate redesign in branch experiments?
+- Should no-silent-path-change tests pin full event payload hashes or core-column-only hashes for long-term maintainability?

+ 29 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/proposal.md

@@ -0,0 +1,29 @@
+## Why
+
+`dragon/v2` has already reached a stable RC1 forward candidate, but the execution core is still a monolithic, order-sensitive rule tree. The biggest remaining risk is no longer a single threshold; it is change safety, explainability, and weak-family governance. Future optimization without structural control will keep exposing core alpha to accidental path drift.
+
+## What Changes
+
+- Introduce OpenSpec-governed phase-3 optimization for `dragon/v2` with RC1 frozen as baseline.
+- Split strategy execution into three explicit layers: `core`, `secondary`, and `bridge`, while keeping compatibility wrappers.
+- Migrate internal control coupling from raw reason-string checks to structured state fields.
+- Restrict weak-family optimization (`deep_oversold_*`, `predictive_*`, `post_sell_rebound_*`) to new research branches with mandatory added/removed trade attribution.
+- Expand no-silent-path-change governance through golden-hash regression and pipeline smoke validation.
+
+## Capabilities
+
+### New Capabilities
+- `layered-rule-engine`: Evaluate rules by explicit `core/secondary/bridge` layers with compatibility-preserving orchestration.
+- `structured-decision-state`: Maintain structured reason/state metadata for both output attribution and internal control transitions.
+- `weak-family-research-governance`: Enforce branch-level isolation and attribution-first evaluation for weak-family optimization.
+- `golden-regression-governance`: Treat RC1 core-hash and release-window summaries as hard guardrails for behavior-preserving refactors.
+
+### Modified Capabilities
+- `dragon-strategy-execution`: Move from monolithic tree-only governance to layered orchestration with compatibility entry points.
+- `strategy-research-workflow`: Shift acceptance from return-only checks to governance-quality checks (attribution, replay stability, rollback readiness).
+
+## Impact
+
+- Affected code (planned): `dragon_strategy.py`, new layered rule modules, structured context/state modules, tests, and reporting scripts.
+- Affected artifacts: `dragon_rc1_golden_manifest.json`, rule-layer attribution outputs, new OpenSpec change package, and migration audit notes.
+- Runtime impact: no intended RC1 behavior change in compatibility phase; behavior-changing experiments remain isolated to new branches.

+ 15 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/specs/golden-regression-governance/spec.md

@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: RC1 baseline SHALL be guarded by core-hash regression
+Behavior-preserving refactors SHALL keep RC1 core regression hashes and release-window summary metrics aligned with the accepted golden manifest unless a behavior-change proposal explicitly updates baseline approval.
+
+#### Scenario: Behavior-preserving refactor is merged
+- **WHEN** no behavior change is declared
+- **THEN** generated RC1 core hashes and summary metrics match the approved golden manifest
+
+### Requirement: Governance validation SHALL include executable test and pipeline gates
+Refactor acceptance SHALL require passing baseline regression tests and at least one daily signal pipeline smoke run to ensure the production chain remains executable.
+
+#### Scenario: Refactor candidate enters review
+- **WHEN** the candidate claims compatibility-preserving changes
+- **THEN** the test suite and signal-pipeline smoke checks pass before acceptance

+ 15 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/specs/layered-rule-engine/spec.md

@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Strategy execution SHALL support explicit layered orchestration
+The strategy engine SHALL evaluate decision logic in explicit `core`, `secondary`, and `bridge` layers under a deterministic orchestration order. Compatibility mode MUST preserve legacy decision order and output schema for behavior-preserving refactors.
+
+#### Scenario: Compatibility mode keeps legacy path order
+- **WHEN** the layered engine runs in compatibility mode on the RC1 baseline dataset
+- **THEN** event/trade outputs remain equivalent to the accepted RC1 golden baseline on core regression fields
+
+### Requirement: Compatibility facade SHALL remain available during migration
+`dragon_strategy.py` SHALL continue to provide a compatibility facade while layered modules are introduced. Downstream pipelines MUST be able to run without immediate consumer rewrites.
+
+#### Scenario: Daily pipeline runs through compatibility facade
+- **WHEN** `dragon_daily_signal_pipeline.py` runs after layered-module introduction
+- **THEN** the pipeline completes successfully without requiring downstream schema migration

+ 16 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/specs/structured-decision-state/spec.md

@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Strategy outputs SHALL carry structured decision metadata
+Strategy events and trades SHALL expose structured reason metadata (`layer`, `family`, `code`) in addition to legacy reason strings. Legacy fields MUST remain available for existing reports during migration.
+
+#### Scenario: Event and trade rows include structured reason metadata
+- **WHEN** strategy run outputs are generated
+- **THEN** each event row includes `reason_layer/reason_family/reason_code`
+- **AND** each trade row includes `buy_reason_*` and `sell_reason_*` structured metadata
+
+### Requirement: Internal control flow SHALL migrate away from reason-string prefix coupling
+Control-flow conditions that depend on prior decision semantics SHALL use structured context fields instead of direct reason-string prefix parsing, except within explicitly marked compatibility adapters.
+
+#### Scenario: Control logic reads structured prior-state fields
+- **WHEN** a rule requires previous entry or exit semantics
+- **THEN** the engine resolves semantics through structured context fields rather than direct raw-string prefix checks

+ 22 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/specs/weak-family-research-governance/spec.md

@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Weak-family optimization SHALL be branch-isolated from frozen RC1
+Optimization experiments on weak families (`deep_oversold_*`, `predictive_*`, `post_sell_rebound_*`) SHALL run in dedicated research branches and MUST NOT directly retune the frozen RC1 branch.
+
+#### Scenario: Weak-family experiment is attempted
+- **WHEN** a weak-family optimization run is proposed
+- **THEN** the implementation targets a dedicated research branch and preserves RC1 baseline behavior unchanged
+
+### Requirement: Weak-family experiments SHALL provide attribution-first evidence
+Any accepted weak-family change SHALL publish added/removed trade attribution versus RC1 baseline and include execution-stress evidence. Return-only claims without attribution MUST NOT pass acceptance.
+
+#### Scenario: Candidate optimization is reviewed
+- **WHEN** a weak-family experiment reports improved aggregate metrics
+- **THEN** acceptance requires added/removed trade evidence and stress outputs in addition to top-level return metrics
+
+### Requirement: Predictive family SHALL be treated as bridge governance scope
+`predictive_*` logic SHALL be governed as bridge/compatibility scope by default, not as core-alpha optimization scope.
+
+#### Scenario: Predictive logic change is introduced
+- **WHEN** a predictive-path modification is proposed
+- **THEN** the change is evaluated under bridge-governance acceptance criteria and not counted as core-alpha improvement evidence

+ 38 - 0
research/dragon/v2/openspec/changes/rc1-layered-governed-optimization/tasks.md

@@ -0,0 +1,38 @@
+## 1. Foundation And Guardrails
+
+- [x] 1.1 Freeze RC1 governance boundary and document branch-role constraints.
+- [x] 1.2 Add structured reason types, decision types, and reason catalog mapping.
+- [x] 1.3 Build RC1 golden baseline manifest with release-window summary and core hashes.
+- [x] 1.4 Add baseline tests for golden-hash regression and reason mapping coverage.
+- [x] 1.5 Run signal-pipeline smoke replay to ensure compatibility path remains runnable.
+
+## 2. Layered Rule-Engine Refactor
+
+- [ ] 2.1 Add `dragon_rule_engine_v2.py` orchestrator with explicit `core -> secondary -> bridge` evaluation order.
+- [ ] 2.2 Extract core rules into `dragon_rules_core.py` without behavior drift.
+- [ ] 2.3 Extract secondary rules into `dragon_rules_secondary.py` without behavior drift.
+- [ ] 2.4 Extract bridge/compatibility rules into `dragon_rules_bridge.py` without behavior drift.
+- [ ] 2.5 Keep `dragon_strategy.py` as compatibility facade and rerun golden regression.
+
+## 3. Structured State Migration
+
+- [ ] 3.1 Add structured context fields (`entry_*`, `last_real_sell_*`, bridge flags).
+- [ ] 3.2 Migrate high-risk string-coupled control paths (`predictive_*`, pending chains) to structured fields.
+- [ ] 3.3 Block new direct prefix-based control checks in refactored modules.
+- [ ] 3.4 Verify no-silent-path-change for compatibility mode.
+
+## 4. Weak-Family Branch Experiments
+
+- [ ] 4.1 Create dedicated research branch for weak-family optimization (do not modify RC1 directly).
+- [ ] 4.2 Implement subtype/confirmation redesign for `deep_oversold_*` in experiment branch.
+- [ ] 4.3 Isolate `predictive_*` as bridge-only family and evaluate structure-preservation cost.
+- [ ] 4.4 Run added/removed trade attribution pack versus RC1 baseline.
+- [ ] 4.5 Run execution-stress replay before any promotion recommendation.
+
+## 5. Test And Reporting Expansion
+
+- [ ] 5.1 Add `test_no_silent_path_change.py` for compatibility-preserving refactors.
+- [ ] 5.2 Add bridge chain regression tests for split-chain behavior.
+- [ ] 5.3 Add weak-family path tests for subtype/pending transitions.
+- [ ] 5.4 Add layered PnL attribution output (`core/secondary/bridge`) and migration audit note.
+- [ ] 5.5 Re-run full suite and publish acceptance summary.

+ 20 - 0
research/dragon/v2/openspec/config.yaml

@@ -0,0 +1,20 @@
+schema: spec-driven
+
+context: |
+  Project: cyb50-quant/research/dragon/v2
+  Domain: rule-based index strategy research for 399673.
+  Governance: RC1 is a frozen forward candidate and must not be directly retuned.
+  Engineering preference: compatibility-first migration, golden regression first, behavior changes only in new branches.
+
+rules:
+  proposal:
+    - Include sections: Why, What Changes, Capabilities, Impact.
+    - Explicitly separate goals and non-goals.
+  design:
+    - Record migration decisions and rollback strategy.
+    - Keep RC1 behavior-preservation constraints explicit.
+  tasks:
+    - Mark completed groundwork as [x] and future work as [ ].
+    - Group tasks by workstream and include validation steps.
+  spec:
+    - Use normative SHALL language and include at least one scenario per requirement.