update conductor files
This commit is contained in:
@@ -1,14 +1,17 @@
|
||||
# Project Context
|
||||
|
||||
## Definition
|
||||
|
||||
- [Product Definition](./product.md)
|
||||
- [Product Guidelines](./product-guidelines.md)
|
||||
- [Tech Stack](./tech-stack.md)
|
||||
|
||||
## Workflow
|
||||
|
||||
- [Workflow](./workflow.md)
|
||||
- [Code Style Guides](./code_styleguides/)
|
||||
|
||||
## Management
|
||||
|
||||
- [Tracks Registry](./tracks.md)
|
||||
- [Tracks Directory](./tracks/)
|
||||
- [Tracks Directory](./tracks/)
|
||||
|
||||
@@ -1,15 +1,18 @@
|
||||
# Product Guidelines: Manual Slop
|
||||
|
||||
## Documentation Style
|
||||
|
||||
- **Strict & In-Depth:** Documentation must follow an old-school, highly detailed technical breakdown style (similar to VEFontCache-Odin). Focus on architectural design, state management, algorithmic details, and structural formats rather than just surface-level usage.
|
||||
|
||||
## UX & UI Principles
|
||||
|
||||
- **USA Graphics Company Values:** Embrace high information density and tactile interactions.
|
||||
- **Arcade Aesthetics:** Utilize arcade game-style visual feedback for state updates (e.g., blinking notifications for tool execution and AI responses) to make the experience fun, visceral, and engaging.
|
||||
- **Explicit Control & Expert Focus:** The interface should not hold the user's hand. It must prioritize explicit manual confirmation for destructive actions while providing dense, unadulterated access to logs and context.
|
||||
- **Multi-Viewport Capabilities:** Leverage dockable, floatable panels to allow users to build custom workspaces suitable for multi-monitor setups.
|
||||
|
||||
## Code Standards & Architecture
|
||||
|
||||
- **Strict State Management:** There must be a rigorous separation between the Main GUI rendering thread and daemon execution threads. The UI should *never* hang during AI communication or script execution. Use lock-protected queues and events for synchronization.
|
||||
- **Comprehensive Logging:** Aggressively log all actions, API payloads, tool calls, and executed scripts. Maintain timestamped JSON-L and markdown logs to ensure total transparency and debuggability.
|
||||
- **Dependency Minimalism:** Limit external dependencies where possible. For instance, prefer standard library modules (like `urllib` and `html.parser` for web tools) over heavy third-party packages.
|
||||
@@ -1,17 +1,21 @@
|
||||
# Technology Stack: Manual Slop
|
||||
|
||||
## Core Language
|
||||
|
||||
- **Python 3.11+**
|
||||
|
||||
## GUI Frameworks
|
||||
|
||||
- **Dear PyGui:** For immediate/retained mode GUI rendering and node mapping.
|
||||
- **ImGui Bundle (`imgui-bundle`):** To provide advanced multi-viewport and dockable panel capabilities on top of Dear ImGui.
|
||||
|
||||
## AI Integration SDKs
|
||||
|
||||
- **google-genai:** For Google Gemini API interaction and explicit context caching.
|
||||
- **anthropic:** For Anthropic Claude API interaction, supporting ephemeral prompt caching.
|
||||
|
||||
## Configuration & Tooling
|
||||
|
||||
- **tomli-w:** For writing TOML configuration files.
|
||||
- **psutil:** For system and process monitoring (CPU/Memory telemetry).
|
||||
- **uv:** An extremely fast Python package and project manager.
|
||||
@@ -19,4 +23,5 @@
|
||||
- **ApiHookClient:** A dedicated IPC client for automated GUI interaction and state inspection.
|
||||
|
||||
## Architectural Patterns
|
||||
- **Event-Driven Metrics:** Uses a custom `EventEmitter` to decouple API lifecycle events from UI rendering, improving performance and responsiveness.
|
||||
|
||||
- **Event-Driven Metrics:** Uses a custom `EventEmitter` to decouple API lifecycle events from UI rendering, improving performance and responsiveness.
|
||||
|
||||
@@ -33,7 +33,7 @@ All tasks follow a strict lifecycle:
|
||||
- Rerun tests to ensure they still pass after refactoring.
|
||||
|
||||
6. **Verify Coverage:** Run coverage reports using the project's chosen tools. For example, in a Python project, this might look like:
|
||||
```bash
|
||||
```powershell
|
||||
pytest --cov=app --cov-report=html
|
||||
```
|
||||
Target: >80% coverage for new code. The specific tools and commands will vary by language and framework.
|
||||
@@ -53,7 +53,7 @@ All tasks follow a strict lifecycle:
|
||||
- **Step 9.1: Get Commit Hash:** Obtain the hash of the *just-completed commit* (`git log -1 --format="%H"`).
|
||||
- **Step 9.2: Draft Note Content:** Create a detailed summary for the completed task. This should include the task name, a summary of changes, a list of all created/modified files, and the core "why" for the change.
|
||||
- **Step 9.3: Attach Note:** Use the `git notes` command to attach the summary to the commit.
|
||||
```bash
|
||||
```powershell
|
||||
# The note content from the previous step is passed via the -m flag.
|
||||
git notes add -m "<note content>" <commit_hash>
|
||||
```
|
||||
@@ -164,21 +164,24 @@ Before marking any task complete, verify:
|
||||
**AI AGENT INSTRUCTION: This section should be adapted to the project's specific language, framework, and build tools.**
|
||||
|
||||
### Setup
|
||||
```bash
|
||||
|
||||
```powershell
|
||||
# Example: Commands to set up the development environment (e.g., install dependencies, configure database)
|
||||
# e.g., for a Node.js project: npm install
|
||||
# e.g., for a Go project: go mod tidy
|
||||
```
|
||||
|
||||
### Daily Development
|
||||
```bash
|
||||
|
||||
```powershell
|
||||
# Example: Commands for common daily tasks (e.g., start dev server, run tests, lint, format)
|
||||
# e.g., for a Node.js project: npm run dev, npm test, npm run lint
|
||||
# e.g., for a Go project: go run main.go, go test ./..., go fmt ./...
|
||||
```
|
||||
|
||||
### Before Committing
|
||||
```bash
|
||||
|
||||
```powershell
|
||||
# Example: Commands to run all pre-commit checks (e.g., format, lint, type check, run tests)
|
||||
# e.g., for a Node.js project: npm run check
|
||||
# e.g., for a Go project: make check (if a Makefile exists)
|
||||
@@ -187,18 +190,21 @@ Before marking any task complete, verify:
|
||||
## Testing Requirements
|
||||
|
||||
### Unit Testing
|
||||
|
||||
- Every module must have corresponding tests.
|
||||
- Use appropriate test setup/teardown mechanisms (e.g., fixtures, beforeEach/afterEach).
|
||||
- Mock external dependencies.
|
||||
- Test both success and failure cases.
|
||||
|
||||
### Integration Testing
|
||||
|
||||
- Test complete user flows
|
||||
- Verify database transactions
|
||||
- Test authentication and authorization
|
||||
- Check form submissions
|
||||
|
||||
### Mobile Testing
|
||||
|
||||
- Test on actual iPhone when possible
|
||||
- Use Safari developer tools
|
||||
- Test touch interactions
|
||||
@@ -208,6 +214,7 @@ Before marking any task complete, verify:
|
||||
## Code Review Process
|
||||
|
||||
### Self-Review Checklist
|
||||
|
||||
Before requesting review:
|
||||
|
||||
1. **Functionality**
|
||||
@@ -246,6 +253,7 @@ Before requesting review:
|
||||
## Commit Guidelines
|
||||
|
||||
### Message Format
|
||||
|
||||
```
|
||||
<type>(<scope>): <description>
|
||||
|
||||
@@ -255,6 +263,7 @@ Before requesting review:
|
||||
```
|
||||
|
||||
### Types
|
||||
|
||||
- `feat`: New feature
|
||||
- `fix`: Bug fix
|
||||
- `docs`: Documentation only
|
||||
@@ -264,7 +273,8 @@ Before requesting review:
|
||||
- `chore`: Maintenance tasks
|
||||
|
||||
### Examples
|
||||
```bash
|
||||
|
||||
```powershell
|
||||
git commit -m "feat(auth): Add remember me functionality"
|
||||
git commit -m "fix(posts): Correct excerpt generation for short posts"
|
||||
git commit -m "test(comments): Add tests for emoji reaction limits"
|
||||
@@ -288,6 +298,7 @@ A task is complete when:
|
||||
## Emergency Procedures
|
||||
|
||||
### Critical Bug in Production
|
||||
|
||||
1. Create hotfix branch from main
|
||||
2. Write failing test for bug
|
||||
3. Implement minimal fix
|
||||
@@ -296,6 +307,7 @@ A task is complete when:
|
||||
6. Document in plan.md
|
||||
|
||||
### Data Loss
|
||||
|
||||
1. Stop all write operations
|
||||
2. Restore from latest backup
|
||||
3. Verify data integrity
|
||||
@@ -303,6 +315,7 @@ A task is complete when:
|
||||
5. Update backup procedures
|
||||
|
||||
### Security Breach
|
||||
|
||||
1. Rotate all secrets immediately
|
||||
2. Review access logs
|
||||
3. Patch vulnerability
|
||||
@@ -312,6 +325,7 @@ A task is complete when:
|
||||
## Deployment Workflow
|
||||
|
||||
### Pre-Deployment Checklist
|
||||
|
||||
- [ ] All tests passing
|
||||
- [ ] Coverage >80%
|
||||
- [ ] No linting errors
|
||||
@@ -321,6 +335,7 @@ A task is complete when:
|
||||
- [ ] Backup created
|
||||
|
||||
### Deployment Steps
|
||||
|
||||
1. Merge feature branch to main
|
||||
2. Tag release with version
|
||||
3. Push to deployment service
|
||||
@@ -330,6 +345,7 @@ A task is complete when:
|
||||
7. Monitor for errors
|
||||
|
||||
### Post-Deployment
|
||||
|
||||
1. Monitor analytics
|
||||
2. Check error logs
|
||||
3. Gather user feedback
|
||||
|
||||
Reference in New Issue
Block a user