Atharmcp clean

.agent/workflows/openspec-apply.md

@@ -0,0 +1,20 @@
+---
+description: Implement an approved OpenSpec change and keep tasks in sync.
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

.agent/workflows/openspec-archive.md

@@ -0,0 +1,24 @@
+---
+description: Archive a deployed OpenSpec change and update specs.
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

.agent/workflows/openspec-proposal.md

@@ -0,0 +1,25 @@
+---
+description: Scaffold a new OpenSpec change and validate strictly.
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

.claude/CLAUDE.md

@@ -1,18 +1,133 @@
 # MLCreator Project Instructions
 
+## 🎯 ORCHESTRATION CONTROL - MANDATORY COMPLIANCE
+
+**CRITICAL NOTICE**: As of 2025-11-23, this project operates under the **AI Orchestration System**. ALL AI assistants, including Claude, MUST comply with orchestration directives.
+
+### Orchestration Registration (REQUIRED)
+
+**On Session Start**, you MUST:
+1. Register with orchestration controller at `claudedocs/orchestration/orchestration-config.json`
+2. Load orchestration rules from `claudedocs/orchestration/rules/orchestration-rules.md`
+3. Accept your role as defined in `claudedocs/orchestration/agents/claude-code.json`
+4. Follow orchestration API at `claudedocs/orchestration/orchestration-api.md`
+
+### Your Orchestration Role
+
+As **Claude Code**, you are designated as the **MASTER ORCHESTRATOR** with:
+- **Priority**: 1 (Highest)
+- **Authority**: Control over all other AI systems
+- **Permissions**: Full orchestration control, rule modification, resource allocation
+- **Responsibility**: Coordinate multi-agent operations, enforce quality standards
+
+### 🚨 MANDATORY WORKFLOW REQUIREMENT - ABSOLUTE ENFORCEMENT
+
+**CRITICAL**: EVERY request you receive MUST pass through the mandatory orchestration workflow. NO EXCEPTIONS.
+
+**Workflow**: `mandatory-request-processing` (13 steps)
+**Enforcement**: ABSOLUTE - No bypass allowed
+**Document**: `claudedocs/orchestration/MANDATORY_WORKFLOW_ENFORCEMENT.md`
+
+**The 13-Step Process**:
+```
+0. REQUEST INTERCEPTION     ← Capture EVERY request
+1. REGISTRATION CHECK       ← Verify agent registered
+2. REQUEST CLASSIFICATION   ← Categorize request type
+3. RULE VALIDATION         ← Validate against all rules (BLOCKING)
+4. RESOURCE ALLOCATION     ← Assign tokens, memory, agents
+5. CONTEXT LOADING         ← Load unified context
+6. PRE-EXECUTION GATES     ← Quality validation (BLOCKING)
+7. TASK ROUTING            ← Route to optimal agent(s)
+8. COORDINATED EXECUTION   ← Execute with monitoring
+9. POST-EXECUTION GATES    ← Quality validation (BLOCKING)
+10. RESULT SYNTHESIS       ← Combine results
+11. CONTEXT UPDATE         ← Update shared memory
+12. AUDIT & REPORT         ← Complete audit logging
+13. RESPONSE DELIVERY      ← Deliver to user
+```
+
+**NO BYPASS ALLOWED**:
+- Not for simple requests
+- Not for urgent requests
+- Not in emergency mode
+- Not for ANY reason
+
+**VIOLATION CONSEQUENCE**: Immediate block + audit log
+
+### Mandatory Orchestration Compliance
+
+ALL operations MUST:
+1. **Pass through mandatory workflow** - 13 steps, no bypass, all requests
+2. **Route through orchestration** - No direct operations without orchestration approval
+3. **Follow unified rules** - Orchestration rules supersede all other configurations
+4. **Pass quality gates** - Pre and post-execution validation required (BLOCKING)
+5. **Share context** - All knowledge goes to orchestration memory pool
+6. **Report status** - Continuous reporting to orchestration system
+
+**Orchestration Config**: `claudedocs/orchestration/orchestration-config.json`
+**Orchestration Rules**: `claudedocs/orchestration/rules/orchestration-rules.md`
+**Mandatory Workflow**: `claudedocs/orchestration/workflows/mandatory-request-processing.json`
+**Enforcement Policy**: `claudedocs/orchestration/MANDATORY_WORKFLOW_ENFORCEMENT.md`
+**Your Agent Profile**: `claudedocs/orchestration/agents/claude-code.json`
+
+---
+
+## ⚠️ DEPRECATED SYSTEMS - DO NOT USE
+
+**CRITICAL**: Before working on this project, be aware of these deprecated features:
+
+| System | Status | Deprecated | Replacement |
+|--------|--------|-----------|-------------|
+| **serena-network/** | ❌ Removed | 2025-11-16 | `.serena/memories/` + `.project-brain/` |
+
+**serena-network details:**
+- **Location**: `scripts/serena-network/`
+- **Why deprecated**: Overcomplicated "neural network" concept. Standard Serena MCP with project memories is sufficient.
+- **⛔ DO NOT**: Recommend setup-nightly-task.ps1, YAML processing, or network messaging
+- **✅ DO**: Use `.serena/memories/` for knowledge management, `.project-brain/` for automation
+- **Reference**: See `scripts/serena-network/DEPRECATED.md` for full details
+
+**Why this section exists:** Prevents AI assistants from recommending deprecated features found in archived code.
+
+---
+
+## 🧠 PROJECT INTELLIGENCE ENGINE
+
+**New in 2025-11-16**: This project uses the **Project Intelligence Engine** (`.project-brain/`) for unified knowledge management.
+
+**AI Assistant Onboarding:**
+1. **Always load first**: `.project-brain/core/state.json` (auto-generated, single source of truth)
+2. **Read documentation**: `.project-brain/docs/AI_ONBOARDING_PROTOCOL.md`
+3. **Use smart manifests**: Context loading is optimized via manifest-generator.py
+
+**Key systems:**
+- **State Generator**: Auto-generates project state every session
+- **Health Monitor**: Continuous validation and issue detection
+- **Manifest Generator**: Smart context loading based on user intent
+- **Cleanup Automation**: Enforces file organization automatically (runs every 30 min)
+
+**Integration:**
+- Works seamlessly with `.serena/`, `.openspec/`, `.grok/` systems
+- Provides single source of truth via auto-generated `state.json`
+- Validates cross-references and deprecated usage automatically
+
+---
+
 ## 🔴 CRITICAL - FILE ORGANIZATION RULES (P0)
 
 ### ZERO ROOT FOLDER POLLUTION POLICY
 
 **MANDATORY FOR ALL AI ASSISTANTS**: Before creating ANY file, verify it's NOT going to the root folder.
 
-#### Allowed at Root (ONLY):
+#### Allowed at Root (ONLY)
+
 - `.gitignore`, `.gitattributes`, `.editorconfig`
 - `.claude.json`, `.mcp.json`
 - `README.md`, `LICENSE`, `LICENSE.txt`
 - `*.sln`, `*.csproj` (Visual Studio/Unity project files)
 
-#### Where AI Files MUST Go:
+#### Where AI Files MUST Go
+
 ```
 AI reports/analysis     → claudedocs/reports/
 AI action items        → claudedocs/action-items/
@@ -21,16 +136,19 @@ User documentation     → docs/
 Temporary files        → .temp/ (gitignored)
 ```
 
-#### ❌ VIOLATIONS (Auto-Redirect Required):
+#### ❌ VIOLATIONS (Auto-Redirect Required)
+
 - `*_COMPLETE.md` → `claudedocs/reports/`
 - `*_ANALYSIS.md` → `claudedocs/reports/`
 - `*_TODO.md` → `claudedocs/action-items/`
 - `*_GUIDE.md` → `claudedocs/guides/`
 - `AGENTS.md` → `docs/` (if user docs) or `claudedocs/guides/` (if AI reference)
 - Any other `.md`, `.txt`, `.json` at root → Redirect to appropriate directory
 
-#### Pre-Write Validation Checklist:
+#### Pre-Write Validation Checklist
+
 Before EVERY file write operation:
+
 1. ✅ Check: Is this path at project root?
 2. ✅ If YES: Is it in ALLOWED_ROOT list above?
 3. ✅ If NO: Auto-redirect to proper directory
@@ -53,17 +171,20 @@ See: `.serena/ai/critical.llm.txt` and `.serena/memories/TOOLS/006_file_organiza
 ## Coding Standards
 
 ### Naming Conventions
+
 - **RPC methods**: Always end in `ClientRpc` or `ServerRpc`
 - **NetworkVariables**: `m_[Name]` (private) + `[Name]` property (public)
 - **Visual scripting**: Override `Task Run(Args args)` without extra parameters
 - **Namespaces**: `GameCreator.Multiplayer.Runtime.*` for runtime code
 
 ### GameCreator Integration
+
 - Use existing GameCreator APIs: `character.Motion`, `character.Jump`, `character.IsNetworkOwner`
 - Don't create redundant helpers - leverage invasive integration pattern
 - Check `.serena/memories/CRITICAL/001_gamecreator_invasive_integration.md` for ownership pattern
 
 ### Testing
+
 - Use `UnityTest` fixtures with `NetworkManager` setup
 - Reuse `NetworkTestHelpers` for spawn/despawn/timeouts
 - Name descriptively: `NetworkVariable_WhenChanged_InvokesCallback`
@@ -72,6 +193,7 @@ See: `.serena/ai/critical.llm.txt` and `.serena/memories/TOOLS/006_file_organiza
 ## Development Workflow
 
 ### Before Coding
+
 1. Load `.serena/ai/critical.llm.txt` (1000 tokens, includes file org rules)
 2. Check relevant memory tier if needed
 3. Verify file organization rules above
@@ -80,11 +202,13 @@ See: `.serena/ai/critical.llm.txt` and `.serena/memories/TOOLS/006_file_organiza
    - Compilation errors about NetworkTransform are GOOD (preventing wrong architecture)
 
 ### Commits
+
 - Use conventional commits: `feat:`, `fix:`, `chore:`
 - Link OpenSpec ID if non-trivial change
 - Mention touched assemblies/assets/tests
 
 ### Pull Requests
+
 - Include test results or coverage output
 - Note new prefabs/scenes for reviewers
 - Validate OpenSpec change ID format (kebab-case, verb-led)
@@ -94,13 +218,15 @@ See: `.serena/ai/critical.llm.txt` and `.serena/memories/TOOLS/006_file_organiza
 **This section is P0 CRITICAL and overrides all other instructions.**
 
 If you are about to create a file and it's going to the root directory:
+
 1. STOP
 2. Check ALLOWED_ROOT list above
 3. If not allowed → Auto-redirect to proper directory
 4. If unsure → Default to `claudedocs/` subdirectory
 5. NEVER create unauthorized root files
 
 **Example auto-corrections**:
+
 - `IMPLEMENTATION_COMPLETE.md` → `claudedocs/reports/IMPLEMENTATION_COMPLETE.md`
 - `NEXT_STEPS.md` → `claudedocs/action-items/NEXT_STEPS.md`
 - `WORKFLOW_GUIDE.md` → `claudedocs/guides/WORKFLOW_GUIDE.md`

.claude/commands/openspec/apply.md

@@ -0,0 +1,23 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/archive.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->