# Provider workspace bootstrap Load the canonical project context first, then the generated AIWG framework context: @WORKSPACE.md @.aiwg/aiwg.config ## Parallelism Cap This project caps parallel agent fan-out (#1359): - **max_parallel_subagents**: 10 (provider default for codex) - **max_parallel_ralph_loops**: 3 (provider default for codex) - **max_parallel_mc_missions**: 6 (provider default for codex) *Rationale*: Provider default for codex — adjust via 'aiwg config set --project parallelism.max_parallel_subagents N' ### Model-selected delegation rubric For each non-trivial task, assess whether it contains independent, bounded subtasks that can run concurrently. When delegation is supported, prefer the deployed model-pinned wrappers by task characteristics and consequence: - `aiwg-model-efficiency-worker`: discovery, inventory, focused edits, and other bounded low-cost work. - `aiwg-model-coding-worker`: implementation, tests, debugging, and routine technical delivery. - `aiwg-model-reasoning-worker`: architecture, synthesis, difficult analysis, and high-consequence review. Do not delegate trivial work, tightly coupled changes, serial dependencies, or tasks likely to collide in shared state; also keep work local when coordination costs exceed the expected benefit. Parallelize only independent work, and take the MIN of provider limits, `max_parallel_subagents`, `AIWG_CONTEXT_WINDOW` budget, framework-specific caps (including the RLM 7-agent hard cap for RLM dispatches), and natural task decomposition. Bump the project cap via `aiwg config set --project parallelism.max_parallel_subagents N`. The primary agent retains orchestration, final integration, conflict resolution, validation, and user-facing accountability. **Provider behavior (codex)**: native custom subagents can select the deployed model-worker wrapper. Verify the resolved model when provider or account policy may substitute it. ## Context Finalization This section is synthesized after template emission from the current workspace state. Preserve operator-authored content outside AIWG-managed blocks; rerun `aiwg regenerate` to refresh this section after provider, framework, or MCP wiring changes. ### Workspace Snapshot - Configured providers: codex - Installed frameworks/addons: all, bt6-maintainer - Recorded deployments: codex - Normalized project context: `.aiwg/AIWG.md` ### Discover-First Protocol Classify every user turn FIRST: is it a **new directive** or a continuation? When a message names or references an AIWG command/capability — even as pasted content like an `address-issues` tracker table, an issue list, or a `flow-*` name — treat it as a new directive and ACT: run `aiwg discover ""`, fetch with `aiwg show `, and invoke it. Do NOT ask "what would you like me to do with these?" when the action is implied — a pasted `address-issues #1234` table means run the address-issues workflow on those issues. Also run `aiwg discover` before declining an AIWG request as out of scope or inventing a workflow from memory. The CLI ranks AIWG capabilities across the installed corpus and rebuilds the index from `$AIWG_ROOT` automatically, so a "no matches" for a command you know is deployed is a bug — not a signal it is absent. Commands AIWG deploys to your provider command directory (`.opencode/command/`, `.claude/commands/`, `~/.codex/prompts/`, …) ARE discoverable this way; fetch them with `aiwg show command `. This prevents decline-without-search failures, ask-instead-of-act on new directives, and hallucinated skill or agent names. Full rule: `agentic/code/addons/aiwg-utils/rules/skill-discovery.md`. ### Engagement Verification When a user asks whether AIWG is active or engaged in this project, run or read `aiwg status --probe --json` and report the result plainly: engaged state, project root, deployed provider files, installed frameworks/addons, and the next action from the probe. Do not add AIWG attribution, signatures, generated-by text, or passive footers to user files, commits, PRs, comments, code headers, or docs. ### Tracker Authority Protocol - Source of truth: [.aiwg/aiwg.config](./.aiwg/aiwg.config) - Canonical tracker: `origin` (github; https://github.com/elder-plinius/OBLITERATUS.git) - Primary repo remote: `origin`; CI remote: `origin` - Secondary/mirror remotes: none configured - Issue storage mode: not configured Tracker access order for issue, PR, release, and CI-sensitive tracker operations: 1. MCP/app tools for the configured tracker. 2. Tracker HTTP API with configured credentials. 3. Tracker CLI for the configured tracker, after confirming authentication. 4. Stop and report a blocker. - Project config decides tracker authority; installed/authenticated CLIs do not. - Git SSH remote access is repository sync, not issue-tracker API access. - Do not file on mirror or secondary remotes just because their CLI is authenticated. - Treat an unauthenticated tracker CLI as one failed access path, then continue probing MCP/app/API before blocking. ### Source Model - `.aiwg/AIWG.md` is the normalized project-local context entry point. - Root `AIWG.md` is the generated cross-provider companion loaded through `AGENTS.md` and provider twins. - `AGENTS.md`, `WARP.md`, `.hermes.md`, and `.github/copilot-instructions.md` are provider-facing bridges, not replacements for `.aiwg/AIWG.md`.