mo/nt8-sdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Harden AI agent rules and compile learning workflow

Browse Source
This commit is contained in:
Mo Hussain
2026-04-05 17:59:34 -04:00
parent 4453ff552a
commit de6e150655
9 changed files with 301 additions and 963 deletions
Download Patch File Download Diff File Expand all files Collapse all files

390
.kilocode/rules/development_workflow.md
View File

@@ -1,344 +1,46 @@
# NT8-SDK — Kilocode Development Workflow
**Last Updated:** 2026-03-27
This is the authoritative workflow for all development work on NT8-SDK using Kilocode.
---
## Division of Labor
| Role | Responsibility |
|---|---|
| **Claude** | Architecture, diagnosis, Kilocode prompt authoring, sequencing |
| **Kilocode** | ALL code implementation — zero exceptions |
| **Mo** | Strategy direction, backtest execution, log collection, go/no-go |
---
## Per-Task Workflow
1. **Claude writes Kilocode prompt** — exact Find/Replace, both file paths, build command, validation checklist
2. **Mo runs Kilocode** — pastes prompt, Kilocode executes
3. **Kilocode reports** — build output + files changed
4. **Mo brings results to Claude** — Kilocode report + session log + CSV
5. **Claude diagnoses** — confirms or issues follow-up prompt
6. **Mo commits:** `git add` → `git commit` → `git push`
7. **Update SPRINT_BOARD** — task to Done or Blocked
---
## Kilocode Prompt Template
```
TASK: [one-line description]
CONTEXT:
[1-3 sentences explaining why]
FILES TO MODIFY:
1. C:\dev\nt8-sdk\src\... [repo path]
2. C:\Users\billy\...\Strategies\... [NT8 path — same change]
CHANGE 1 — [description]:
File: [path]
Find:
[exact existing code]
Replace with:
[new code]
BUILD & DEPLOY:
1. dotnet build NT8-SDK.sln --configuration Release
2. deployment\deploy-to-nt8.bat
3. NT8: Tools → Edit NinjaScript → open NT8StrategyBase.cs → save
VALIDATION:
- Run Strategy Analyzer: NQ JUN26, Jan 1 2026 → Mar 27 2026
- Look for in session log: [specific confirmation lines]
```
---
## Guardrails — Kilocode MUST NEVER
1. Modify files outside the task spec
2. Use C# 6+ syntax
3. Remove existing comments or XML documentation
4. Change interface signatures
5. Deploy without building first
6. Edit NT8 path without also updating repo path
7. Guess NT8 API signatures
8. Introduce async/await
---
## Log Analysis Quick Reference
**Healthy dual-leg trade in session log:**
```
SIGNAL Sell | Grade=A | Score=0.820
SUBMIT Scaler=1 Runner=1 Stop=8 Target=20
FILL Short 1 @ XXXXX <- scaler fill
PNL_UPDATE Position=Short Qty=1
FILL Short 1 @ XXXXX <- runner fill
PNL_UPDATE Position=Short Qty=2 <- CRITICAL: Qty=2 = runner entered
```
**Warning signs:**
- SUBMIT then only 1 FILL → runner blocked (check EntriesPerDirection + MaxOpenPositions)
- Multiple SIGNALs in milliseconds → replay burst (_realtimeBarSeen not working)
- SIGNAL then nothing → ProcessStrategyIntent guard blocking backtest
---
## Commit Message Format
```
feat: description <- new feature
fix: description <- bug fix
refactor: description <- no behavior change
test: description <- tests only
docs: description <- documentation only
```
---
## Original Archon Workflow (2025, archived below)
## Archon Workflow Principles
The development process follows these core principles adapted from the Archon workflow:
### 1. Check Current Task
Before beginning any work, clearly define what needs to be accomplished:
- Review requirements and specifications
- Understand success criteria
- Identify dependencies and blockers
### 2. Research for Task
Conduct thorough research before implementation:
- Review existing code and documentation
- Understand best practices and patterns
- Identify potential challenges and solutions
### 3. Implement the Task
Execute the implementation with focus and precision:
- Follow established patterns and conventions
- Write clean, maintainable code
- Include comprehensive error handling
- Add structured logging for observability
### 4. Update Task Status
Track progress and document completion:
- Mark tasks as completed in the todo list
- Document any issues or deviations
- Note lessons learned for future reference
### 5. Get Next Task
Move systematically through the implementation:
- Prioritize tasks based on dependencies
- Focus on one task at a time
- Ensure quality before moving forward
## Development Process
### Phase 1: Planning and Design
1. Review specifications and requirements
2. Create architecture diagrams and documentation
3. Identify core components and their interactions
4. Plan implementation approach and timeline
### Phase 2: Environment Setup
1. Create project structure and configuration files
2. Set up build and test infrastructure
3. Configure CI/CD pipeline
4. Verify development environment
### Phase 3: Core Implementation
1. Implement core interfaces and models
2. Develop risk management components
3. Create position sizing algorithms
4. Build supporting utilities and helpers
### Phase 4: Testing and Validation
1. Create comprehensive unit tests
2. Implement integration tests
3. Run validation scripts
4. Verify all success criteria
### Phase 5: Documentation and Delivery
1. Create developer documentation
2. Write user guides and examples
3. Prepare release notes
4. Conduct final validation
## Code Quality Standards
### 1. Code Structure
- Follow established naming conventions
- Use consistent formatting and style
- Organize code into logical modules
- Maintain clear separation of concerns
### 2. Error Handling
- Validate all inputs and parameters
- Provide meaningful error messages
- Handle exceptions gracefully
- Log errors for debugging
### 3. Testing
- Write unit tests for all public methods
- Include edge case testing
- Validate error conditions
- Maintain >90% code coverage
### 4. Documentation
- Include XML documentation for all public APIs
- Add inline comments for complex logic
- Document configuration options
- Provide usage examples
## Git Workflow
### Branching Strategy
- Use feature branches for all development
- Create branches from main for new features
- Keep feature branches short-lived
- Merge to main after review and testing
### Commit Guidelines
- Write clear, descriptive commit messages
- Make small, focused commits
- Reference issues or tasks in commit messages
- Squash related commits before merging
### Pull Request Process
- Create PRs for all feature work
- Include description of changes and testing
- Request review from team members
- Address feedback before merging
## Development Environment
### Required Tools
- .NET 6.0 SDK
- Visual Studio Code or Visual Studio
- Git for version control
- Docker Desktop (recommended)
### Recommended Extensions
- C# for Visual Studio Code
- EditorConfig for VS Code
- GitLens for enhanced Git experience
- Docker extension for container management
## Build and Test Process
### Local Development
1. Restore NuGet packages: `dotnet restore`
2. Build solution: `dotnet build`
3. Run tests: `dotnet test`
4. Run specific test categories if needed
### Continuous Integration
- Automated builds on every commit
- Run full test suite on each build
- Generate code coverage reports
- Deploy to test environments
## Debugging and Troubleshooting
### Common Issues
1. **Build Failures**
- Check for missing NuGet packages
- Verify .NET SDK version
- Ensure all projects reference correct frameworks
2. **Test Failures**
- Review test output for specific errors
- Check test data and setup
- Verify mock configurations
3. **Runtime Errors**
- Check logs for error details
- Validate configuration settings
- Review dependency injection setup
### Debugging Tools
- Visual Studio debugger
- Console logging
- Structured logging with correlation IDs
- Performance profiling tools
## Release Process
### Versioning
- Follow semantic versioning (MAJOR.MINOR.PATCH)
- Increment version in Directory.Build.props
- Update release notes with changes
- Tag releases in Git
### Deployment
- Create NuGet packages for SDK components
- Publish to internal package repository
- Update documentation with release notes
- Notify stakeholders of new releases
## Best Practices
### 1. Code Reviews
- Review all code before merging
- Focus on correctness, maintainability, and performance
- Provide constructive feedback
- Ensure adherence to coding standards
### 2. Performance Considerations
- Minimize allocations in hot paths
- Use efficient data structures
- Cache expensive operations
- Profile performance regularly
### 3. Security
- Validate all inputs
- Sanitize user data
- Protect sensitive configuration
- Follow secure coding practices
### 4. Maintainability
- Write self-documenting code
- Use meaningful variable and method names
- Keep methods small and focused
- Refactor regularly to improve design
## Task Management Without Archon
Since we're not using the Archon MCP server, we'll manage tasks using:
1. **Todo Lists**: Track progress using markdown checklists
2. **Documentation**: Maintain detailed records of implementation decisions
3. **Git**: Use commits and branches to track work progress
4. **Issue Tracking**: Use GitHub Issues or similar for task management
### Task Status Tracking
- **Todo**: Task identified but not started
- **In Progress**: Actively working on task
- **Review**: Task completed, awaiting validation
- **Done**: Task validated and completed
## Communication and Collaboration
### Team Coordination
- Hold regular standups to discuss progress
- Use collaborative tools for communication
- Document architectural decisions
- Share knowledge and best practices
### Knowledge Sharing
- Conduct code walkthroughs for complex features
- Create technical documentation
- Share lessons learned from issues
- Mentor new team members
## Conclusion
This development workflow ensures consistent, high-quality implementation of the NT8 Institutional SDK. By following these principles and practices, we can deliver a robust, maintainable, and scalable trading platform that meets institutional requirements for risk management and performance.
The workflow emphasizes systematic progress, quality assurance, and continuous improvement. Each task should be approached with thorough research, careful implementation, and comprehensive validation to ensure the highest quality outcome.
# NT8-SDK Development Workflow
**Last Updated:** 2026-04-05
Operational workflow for Kilo/Codex-assisted development.
## Per-Task Workflow (Required)
1. **Confirm scope**
- [ ] Confirm exact files allowed by task spec.
- [ ] Cross-check `.kilocode/rules/file_boundaries.md`.
2. **Set task state**
- [ ] Move task status from `todo` -> `doing` before edits.
3. **Implement**
- [ ] Make minimum-diff changes only in scoped files.
4. **Verify**
- [ ] Run `.\verify-build.bat` per `.kilocode/rules/verification_requirements.md`.
- [ ] Run focused tests required by changed area.
5. **NT8 compile/deploy checks** (when NinjaScript files are touched)
- [ ] Validate signatures against official NT8 docs.
- [ ] Run repo build/deploy sequence required for NT8.
- [ ] Compile in NinjaScript Editor (authoritative NT8 check).
6. **Documentation updates**
- [ ] Update `docs/00-governance/active_work.md` when task status or blockers changed.
- [ ] Update `docs/00-governance/roadmap.md` when sequencing/scope changed.
- [ ] Update `docs/00-governance/decisions.md` when durable architecture decisions were made.
- [ ] Update `CLEANUP_LOG.md` when cleanup debt status changed.
7. **Compile-learning capture** (if any compile issue occurred)
- [ ] Add prevention rule to `docs/00-governance/compile_guardrails.md`.
- [ ] Add error fingerprint + fix to `docs/00-governance/common_failures.md`.
- [ ] Add pattern/anti-pattern to `docs/00-governance/patterns_and_antipatterns.md`.
8. **Set task state and report**
- [ ] Move task status from `doing` -> `review`.
- [ ] Report changed files and verification evidence.
## Definition of Done (Required)
- [ ] Only scoped files changed.
- [ ] Verification gates passed.
- [ ] NT8 compile checks completed when relevant.
- [ ] Relevant governance docs updated.
- [ ] Compile learnings captured when applicable.
- [ ] Task moved to `review` with evidence.
## Out-of-Scope Safety
- [ ] Do not modify files outside task scope.
- [ ] Do not apply opportunistic refactors.
- [ ] Do not modify historical/contextual docs unless explicitly requested.
- [ ] If a real fix needs out-of-scope changes, stop and report a scope blocker.