Establish governance docs as canonical repo context
This commit is contained in:
@@ -6,6 +6,19 @@ This is **production trading software**. Bugs cause real financial losses. Never
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Onboarding / First Read (Canonical Order)
|
||||||
|
|
||||||
|
For every new Kilo session, start with `docs/00-governance/` as the primary source of truth:
|
||||||
|
1. `docs/00-governance/executive_summary.md`
|
||||||
|
2. `docs/00-governance/current_status.md`
|
||||||
|
3. `docs/00-governance/active_work.md`
|
||||||
|
4. `docs/00-governance/architecture.md`
|
||||||
|
5. `docs/00-governance/roadmap.md`
|
||||||
|
|
||||||
|
`PROJECT_HANDOVER.md` and `DESIGNED_VS_IMPLEMENTED_GAP_ANALYSIS.md` are historical/contextual references only. Use them for background, not for authoritative current direction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Critical Rules for Kilocode
|
## Critical Rules for Kilocode
|
||||||
|
|
||||||
1. **Only modify files listed in the task spec.** Never touch adjacent code.
|
1. **Only modify files listed in the task spec.** Never touch adjacent code.
|
||||||
|
|||||||
13
docs/00-governance/CLEANUP_LOG.md
Normal file
13
docs/00-governance/CLEANUP_LOG.md
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
# Governance Cleanup Log
|
||||||
|
|
||||||
|
## 2026-04-05
|
||||||
|
- Established `docs/00-governance/` as canonical governance entry point.
|
||||||
|
- Added concise governance baseline documents:
|
||||||
|
- `executive_summary.md`
|
||||||
|
- `architecture.md`
|
||||||
|
- `current_status.md`
|
||||||
|
- `roadmap.md`
|
||||||
|
- `active_work.md`
|
||||||
|
- Updated onboarding guidance in `.kilocode/rules/project_context.md` to point new sessions to governance docs first.
|
||||||
|
- Reclassified `PROJECT_HANDOVER.md` and `DESIGNED_VS_IMPLEMENTED_GAP_ANALYSIS.md` as historical/contextual references, not primary truth.
|
||||||
|
- No code files modified and no file moves performed.
|
||||||
@@ -0,0 +1,17 @@
|
|||||||
|
# Active Work
|
||||||
|
|
||||||
|
## Current Execution Focus
|
||||||
|
- Validate runner-leg dual-fill behavior in Strategy Analyzer/session logs.
|
||||||
|
- Close remaining Sprint 2 hardening items already identified in task specs.
|
||||||
|
- Preserve strict compile and deployment verification sequence for every change.
|
||||||
|
|
||||||
|
## In-Scope Hardening Themes
|
||||||
|
- Strategy safety controls and execution circuit-breaker wiring.
|
||||||
|
- Trailing stop calculation correctness.
|
||||||
|
- Logging verbosity controls for production noise reduction.
|
||||||
|
- Session/holiday awareness to avoid invalid trading windows.
|
||||||
|
|
||||||
|
## Working Rules
|
||||||
|
- Apply changes only to explicitly scoped files per task.
|
||||||
|
- Keep NT8 API signatures and managed-order sequencing exact.
|
||||||
|
- Maintain C# 5.0 compatibility and existing interface boundaries.
|
||||||
|
|||||||
@@ -0,0 +1,28 @@
|
|||||||
|
# Architecture Governance
|
||||||
|
|
||||||
|
## Runtime Flow (Authoritative)
|
||||||
|
```
|
||||||
|
SimpleORBNT8.cs
|
||||||
|
-> NT8StrategyBase.cs
|
||||||
|
-> SimpleORBStrategy.cs
|
||||||
|
-> NT8OrderAdapter.cs
|
||||||
|
-> PortfolioRiskManager.cs
|
||||||
|
-> NinjaTrader 8
|
||||||
|
```
|
||||||
|
|
||||||
|
## Responsibilities
|
||||||
|
- `SimpleORBNT8.cs`: NT8 entry point and platform lifecycle bridge.
|
||||||
|
- `NT8StrategyBase.cs`: orchestration, risk gate sequencing, execution handoff, platform callbacks.
|
||||||
|
- `SimpleORBStrategy.cs`: signal generation and confluence grading only.
|
||||||
|
- `NT8OrderAdapter.cs`: execution bridge to NT8 managed order APIs.
|
||||||
|
- `PortfolioRiskManager.cs`: cross-strategy risk controls and account-level enforcement.
|
||||||
|
|
||||||
|
## Architectural Constraints
|
||||||
|
- Risk-first flow is mandatory; no strategy-level bypass of risk validation.
|
||||||
|
- Managed-order sequence remains required (`SetStopLoss` / `SetProfitTarget` before entry).
|
||||||
|
- C# 5.0 syntax only, .NET Framework 4.8 only.
|
||||||
|
- NT8 signatures must be verified against official NinjaTrader docs before API-touching edits.
|
||||||
|
|
||||||
|
## Governance Notes
|
||||||
|
- Core Risk/Sizing/OMS/Intelligence/Analytics layers are treated as complete and stable unless explicitly re-opened by approved work.
|
||||||
|
- Hardening changes are concentrated in targeted adapter/utility components per active-work scope.
|
||||||
|
|||||||
@@ -0,0 +1,20 @@
|
|||||||
|
# Current Status
|
||||||
|
|
||||||
|
## Snapshot (2026-04-05)
|
||||||
|
- Program phase: Sprint 2 SIM validation with production-hardening follow-through.
|
||||||
|
- Core implementation: complete across major layers with 240+ passing tests.
|
||||||
|
- Live focus: execution safety, validation depth, and operational reliability.
|
||||||
|
|
||||||
|
## Confirmed Working Areas
|
||||||
|
- End-to-end strategy pipeline from signal -> risk -> sizing -> NT8 managed execution.
|
||||||
|
- Session handling, portfolio risk controls, and base strategy orchestration.
|
||||||
|
- Existing analytics/risk/sizing/OMS foundations remain stable.
|
||||||
|
|
||||||
|
## Open Findings Driving Work
|
||||||
|
- Runner leg behavior requires explicit validation evidence (`Qty=2` path confirmation).
|
||||||
|
- Risk/config consistency checks need tightening in runtime safeguards.
|
||||||
|
- Operational controls (CI automation, alerting, and out-of-sample validation) remain pending.
|
||||||
|
|
||||||
|
## Operational Reality
|
||||||
|
- `dotnet build` success is necessary but not sufficient; NT8 NinjaScript compile remains a separate required validation step.
|
||||||
|
- Deployment integrity requires keeping repo and NT8 runtime strategy copies synchronized.
|
||||||
|
|||||||
@@ -0,0 +1,20 @@
|
|||||||
|
# Executive Summary
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
- This folder (`docs/00-governance/`) is the canonical governance source for project state, priorities, architecture intent, and active execution guidance.
|
||||||
|
- Governance is aligned to Sprint 2 (SIM validation) with production hardening gaps tracked and prioritized.
|
||||||
|
|
||||||
|
## Current Position (2026-04-05)
|
||||||
|
- Core engine is implemented with 240+ passing tests across core components.
|
||||||
|
- NT8 execution path is wired and validated in SIM for baseline operation.
|
||||||
|
- Remaining work is focused on closing operational hardening gaps and validating runner behavior under production-like conditions.
|
||||||
|
|
||||||
|
## Approved Direction
|
||||||
|
- Keep execution in managed-order NT8 patterns and C# 5.0 / .NET Framework 4.8 constraints.
|
||||||
|
- Complete critical and high-priority hardening tasks before expanding strategy scope.
|
||||||
|
- Treat historical handover artifacts as context only; governance decisions flow from this folder.
|
||||||
|
|
||||||
|
## Immediate Priorities
|
||||||
|
- Confirm runner-leg dual-fill behavior in analyzer/session logs.
|
||||||
|
- Close safety and observability items already identified in Sprint 2/3 gap tracking.
|
||||||
|
- Maintain strict file-boundary and compile-guardrail discipline for all changes.
|
||||||
|
|||||||
@@ -0,0 +1,21 @@
|
|||||||
|
# Roadmap
|
||||||
|
|
||||||
|
## Sprint 2 (Active): SIM Validation
|
||||||
|
- Validate dual-leg execution behavior with log evidence.
|
||||||
|
- Complete remaining safety/consistency fixes tied to active gap list.
|
||||||
|
- Exit criteria: stable SIM behavior with no unresolved critical gaps.
|
||||||
|
|
||||||
|
## Sprint 3: Production Hardening
|
||||||
|
- Implement CI build/test automation and operational alerting.
|
||||||
|
- Complete lower-priority runtime consistency and observability improvements.
|
||||||
|
- Add walk-forward and broader validation coverage beyond in-sample checks.
|
||||||
|
|
||||||
|
## Sprint 4: Live Capital Readiness
|
||||||
|
- Gate on sustained SIM metrics and drawdown controls.
|
||||||
|
- Introduce go-live runbook and operational controls for controlled capital exposure.
|
||||||
|
|
||||||
|
## Sprint 5: ML Extension (Deferred)
|
||||||
|
- Add inference integration only after sufficient live/sim data and stable production operations.
|
||||||
|
|
||||||
|
## Sequencing Rule
|
||||||
|
- No feature expansion ahead of unresolved safety and validation gates.
|
||||||
|
|||||||
Reference in New Issue
Block a user