OBLITERATUS/AIWG.md

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 "<the need>", fetch with aiwg show <type> <name>, 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 <name>. 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
• 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.