|
| 1 | +# Plugin Lifecycle Policy |
| 2 | + |
| 3 | +[简体中文](./plugin_lifecycle_policy.zh-CN.md) |
| 4 | + |
| 5 | +This document defines the lifecycle ladder and gate model for strategy plugins. |
| 6 | + |
| 7 | +## Design Goal |
| 8 | + |
| 9 | +Plugins should be easy to observe, hard to misuse, and very hard to let affect |
| 10 | +capital without explicit approval. |
| 11 | + |
| 12 | +- AI may monitor and summarize plugin evidence. |
| 13 | +- AI must not upgrade a plugin into live authority by itself. |
| 14 | +- Notification delivery is not the same as position-control authority. |
| 15 | +- Compatibility mounts can exist for history, but they should not expand live |
| 16 | +permission by accident. |
| 17 | + |
| 18 | +## Recommended Plugin Stages |
| 19 | + |
| 20 | +| Stage | Meaning | Capital impact | |
| 21 | +| --- | --- | --- | |
| 22 | +| `research_only` | Research artifact, not meant for platform runtime | none | |
| 23 | +| `notification_only` | Can notify humans, but cannot control position | none | |
| 24 | +| `shadow_observer` | Can be attached to runtime metadata and audit trails | none | |
| 25 | +| `automation_candidate` | Has enough evidence to be considered for automation | gated | |
| 26 | +| `automation_approved` | Strategy-side automation is allowed when the platform gate also passes | yes | |
| 27 | +| `deprecated_compatibility` | Kept for replay or staged migration only | none | |
| 28 | + |
| 29 | +## Three-Gate Rule |
| 30 | + |
| 31 | +For any plugin-driven capital impact, all three gates must pass: |
| 32 | + |
| 33 | +1. **Plugin schema gate** |
| 34 | + - The artifact must match a supported schema version and remain in `shadow` |
| 35 | + mode for the shared contract. |
| 36 | +2. **Plugin evidence gate** |
| 37 | + - The plugin must be marked `automation_approved` and |
| 38 | + `position_control_allowed = true`. |
| 39 | +3. **Strategy/platform gate** |
| 40 | + - The consuming strategy must explicitly opt in to the plugin and remain |
| 41 | + allowed by the platform catalog. |
| 42 | + |
| 43 | +If any gate fails, the plugin should stay notification-only or compatibility-only. |
| 44 | + |
| 45 | +## Current Policy Shape |
| 46 | + |
| 47 | +- `src/quant_strategy_plugins/plugin_policies.py` is the machine-readable source |
| 48 | + for lifecycle, consumption, notification-target, schema-version, and |
| 49 | + deprecated-successor policy. |
| 50 | +- `market_regime_control` is the unified default runtime plugin. |
| 51 | +- `crisis_response_shadow`, `macro_risk_governor`, and `taco_rebound_shadow` |
| 52 | + remain compatibility mounts or notification-only sidecars. |
| 53 | +- `panic_reversal_shadow` remains research-heavy and should stay notification-only |
| 54 | + unless it is separately promoted. |
| 55 | + |
| 56 | +## Recommended Operating Rules |
| 57 | + |
| 58 | +- Keep `notification_allowed` broad for research visibility. |
| 59 | +- Keep `position_control_allowed` narrow and explicit. |
| 60 | +- Prefer a single shared policy registry instead of spreading allowlists across |
| 61 | + runners. |
| 62 | +- When a strategy consumes a plugin for live capital impact, keep the platform |
| 63 | + notification path separate from the strategy execution path. |
| 64 | + |
| 65 | +## Practical Interpretation |
| 66 | + |
| 67 | +- If the artifact is only for human review, use `notification_only`. |
| 68 | +- If the artifact is still a sidecar evidence layer, use `shadow_observer`. |
| 69 | +- If the plugin is being prepared for automation, keep it in |
| 70 | + `automation_candidate` until the strategy gate also passes. |
| 71 | +- If the plugin is no longer the preferred path, mark it |
| 72 | + `deprecated_compatibility` and keep it out of new runtime defaults. |
0 commit comments