Initial commit: a0_software_orchestrator v1.0

- Auto-Registration-Bug behoben (register_project/get_project_id/resolve_project Trennung)
- 25 Tests gruen (Pytest)
- block_compactor-Tool refactored (Option B: Soft-Check statt Hard-Block)
- 4 Restbaustellen gefixt
- DB-Schema: plugin_settings-Tabelle hinzugefuegt
- 3 Schattenprojekte aus DB geloescht
- Plan v3 + Refactor-Plan + Worklog dokumentiert

help/management/context-budgeting.md

@@ -0,0 +1,36 @@
+---
+name: context-budgeting
+description: Manager context small, raw data to files, token estimation workflow for the orchestrator agent.
+tags: ['management', 'context', 'tokens']
+---
+
+# Context Budgeting
+
+## Purpose
+Keep the main agent's context small by storing raw data in files and using includes/references instead of inline data.
+
+## When to Use
+- When a tool returns more than 80 lines of text
+- When the user provides large files for processing
+- When the conversation history grows large
+- When a subordinate returns a long report
+
+## When Not to Use
+- For short tool outputs (< 30 lines)
+- For data that must be reasoned about inline
+
+## Procedure
+1. Receive large output from tool or subordinate
+2. Save to a file (e.g., /a0/usr/workdir/<name>.md)
+3. Reference the file in the response: `See §include(/path/to/file.md)`
+4. Optionally summarize the file in a few lines for context
+5. Use raw file only when deep analysis is needed
+
+## Token Estimation Rule
+- 1 line of code/markdown ≈ 10-20 tokens
+- 80 lines of tool output ≈ 1000-1500 tokens
+- 1000 lines of conversation ≈ 15000-20000 tokens
+- Compress when output exceeds 1000 tokens
+
+## See Also
+- Tool: `context_compactor` (plugin tool for structured compression)

help/management/errors.md

@@ -0,0 +1,38 @@
+---
+name: error-tracking
+description: Known errors lifecycle management and recovery for the orchestrator agent.
+tags: ['management', 'errors', 'tracking']
+---
+
+# Error Tracking
+
+## Purpose
+Track known errors across sessions, document their root cause and solution, and reuse the knowledge for future occurrences.
+
+## When to Use
+- When a tool or subordinate returns a persistent error
+- When a code block fails compilation or tests
+- When the agent encounters an unknown error
+- After resolution to log the solution
+
+## When Not to Use
+- For transient network blips (retry once, then log)
+- For user input errors (request clarification instead)
+
+## Procedure: Error Logging
+1. Capture full error output (stack trace, message, context)
+2. Search the library for similar past errors (use library-query)
+3. If a similar error exists, apply the documented solution
+4. If new error, document: title, symptom, cause, fix, tags, project_id
+5. Extract to library (use library-extractor) for future reference
+
+## Procedure: Resolution
+1. Apply minimal targeted fix
+2. Run tests to verify
+3. Commit the fix
+4. Update error entry with resolution status
+
+## See Also
+- Help: `library/extract.md`
+- Help: `library/query.md`
+- Tool: `error_handler` (if available in plugin)

help/management/tool-governance.md

@@ -0,0 +1,40 @@
+---
+name: tool-governance
+description: Tool registry, capability checks, and fallback handling for the orchestrator agent.
+tags: ['management', 'tools', 'registry']
+---
+
+# Tool Governance
+
+## Purpose
+Maintain a registry of available tools, verify capabilities before use, and define fallback behavior when a tool is unavailable.
+
+## When to Use
+- Before invoking any tool for the first time
+- When a tool returns an unexpected error
+- When the agent needs to discover what tools exist
+- During phase transitions
+
+## When Not to Use
+- For well-known core tools (terminal, browser, code execution)
+- For tools just confirmed working in this session
+
+## Procedure: Tool Discovery
+1. Use the `tool_registry` plugin tool to list available tools
+2. Read tool documentation from help/<topic>/help.md
+3. Note required inputs, expected outputs, error modes
+
+## Procedure: Capability Check
+1. Verify the tool exists in registry
+2. Verify all required inputs are available
+3. Verify the tool is enabled (not toggled off)
+4. If any check fails: see Fallback
+
+## Procedure: Fallback
+- Tool not found: use `capability_check` to find closest alternative
+- Tool disabled: ask user to enable or use alternative
+- Tool errors persistently: delegate to test_debug_engineer for diagnosis
+
+## See Also
+- Plugin tool: `tool_registry`
+- Plugin tool: `capability_check`