# AIWG.md
<!-- aiwg-managed -->
<!-- Normalized project-local AIWG context. Operator notes may live outside AIWG-managed blocks. -->

This file is the stable `.aiwg/AIWG.md` entry point for AIWG skills, rules, and generated provider context.

<!-- aiwg-context-finalization:START -->
## 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](./aiwg.config)
- Internal/canonical tracker: `origin` (github; https://github.com/elder-plinius/OBLITERATUS.git)
- Customer issue tracker: not configured
- 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.
- Route internal engineering, delivery, and CI-sensitive issue work to the internal tracker.
- Route customer acknowledgements, follow-up, and closure to the customer tracker when configured.
- 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`.
<!-- aiwg-context-finalization:END -->
