ashmitb95 · ashmitb95 · May 31, 2026 · May 31, 2026
diff --git a/AGENTS.md b/AGENTS.md
diff --git a/README.md b/README.md
diff --git a/docs/architecture.md b/docs/architecture.md
diff --git a/docs/architecture/providers.md b/docs/architecture/providers.md
@@ -1,7 +1,7 @@
 # Provider Injection — Issue Providers
 
-> **Status:** v1 design reference. Code lands in M5 (see [`docs/plans/INDEX.md`](../plans/INDEX.md)).
-> **Plan:** [`docs/plans/archive/providers-arch.md`](../plans/archive/providers-arch.md) (the historical spec; this doc is the live artifact).
+> **Status:** Implemented in M5 (Linear + GitHub Issues providers; see CHANGELOG.md).
+> **Historical design:** The M0 design doc is archived. This doc is the live artifact.
 > **Scope:** issue providers only in v1. Other use cases named in §8 but not specified.
 
 Canopy's read tools today are tightly coupled to specific external services — `linear_get_issue`, `linear_my_issues`, etc. all call directly into [`src/canopy/integrations/linear.py`](../../src/canopy/integrations/linear.py). That works while we use exactly those services, but the moment we want GitHub Issues (or JIRA, or anything else) instead of Linear, every action that touches issue context has to branch on which integration to call. That branching ages badly and bleeds Linear-shaped assumptions into the contract.
@@ -357,7 +357,7 @@ class GitHubIssuesProvider:
 
 The following could adopt the same provider-injection shape if implementation drops in seamlessly. **None are scheduled here.** Effort cap on retrofitting any of them: < 5% of the M5 implementation effort. If retrofitting requires non-trivial refactor, leave the existing handling alone.
 
-- **Bot-author detection** — currently a hardcoded `author_type == "Bot"` substring check. Could become a `BotAuthorDetector` provider with per-team rules (CodeRabbit-style only, JIRA-bot, custom regex, etc.). M3 (bot-tracking) introduces `review_bots` augment as the v1 mechanism; provider-ifying is a future option.
+- **Bot-author detection** — M3 (bot-tracking, shipped) introduced `review_bots` augment in canopy.toml for per-team configuration. `author_type == "Bot"` checks are already provider-aware via GitHub Issues. Future: could extend to a full `BotAuthorDetector` provider with custom rules (regex, allowlist, etc.), but `review_bots` meets current needs.
 - **CI providers** (GitHub Actions, CircleCI, Buildkite) — deferred to the [ci-status plan](../plans/ci-status.md). Same shape would apply: a `CIProvider` protocol with `get_check_runs(pr)` etc. Don't build until that plan exists.
 - **Code-review platforms** (GitHub, GitLab, Bitbucket) — `gh` fallback works today via [`integrations/github.py`](../../src/canopy/integrations/github.py). A `ReviewPlatformProvider` could unify, but the existing gh-or-MCP pattern handles current needs.
 - **IDE workspace formats** (VS Code `.code-workspace`, JetBrains `.idea/`, Cursor) — [worktree-bootstrap plan](../plans/worktree-bootstrap.md) defers this. Could become an `IDEWorkspaceWriter` provider.

diff --git a/docs/test-plan.md → docs/archive/test-plan.md b/docs/test-plan.md → docs/archive/test-plan.md
diff --git a/docs/test-findings.md b/docs/test-findings.md
diff --git a/docs/workspace.md b/docs/workspace.md
diff --git a/github-issue-active-context.md b/github-issue-active-context.md
diff --git a/src/canopy/agent_setup/skills/augment-canopy/SKILL.md b/src/canopy/agent_setup/skills/augment-canopy/SKILL.md
@@ -47,7 +47,7 @@ augments = { preflight_cmd = "uv run pytest tests/fast" }   # api-only override
 |---|---|---|---|
 | `preflight_cmd` | string | `canopy preflight` (and `review_prep` path inside `coordinator.py`) | Runs via `sh -c` so pipes / `&&` chains work |
 | `test_cmd` | string | future `canopy test` (not v1) | Schema-reserved; safe to set |
-| `review_bots` | list[string] | M3 bot-comment tracking (when shipped) | Workspace-level only; per-repo overrides ignored for this key |
+| `review_bots` | list[string] | M3 bot-comment tracking | Workspace-level only; per-repo overrides ignored for this key |
 | `auto_resolve_threads_on_address` | bool | `canopy commit --address <id>` | When true, `canopy commit --address <id>` auto-resolves the corresponding GH review thread after push. `--no-resolve-thread` overrides. Default: false. |
 
 Unknown keys are silently preserved by the parser — future augments don't require schema migration.
@@ -86,7 +86,7 @@ Agent should:
    > - `augments.preflight_cmd = "ruff check . && pyright"`
    > - `augments.review_bots = ["coderabbit", "korbit"]`
    >
-   > The next `canopy preflight` will run the new command. Bot-comment tracking will pick up the `review_bots` list once M3 ships.
+   > The next `canopy preflight` will run the new command. Bot-comment tracking uses the `review_bots` list.
 
 ## Per-repo override example
 
@@ -111,6 +111,6 @@ Atomic write, confirm:
 
 ## Don't
 
-- Don't add validation logic here — the parser is intentionally lenient. Validation (typo detection, unknown-key warnings) lives in `canopy doctor` (deferred).
+- Don't add validation logic here — the parser is intentionally lenient. Validation (typo detection, unknown-key warnings) lives in `canopy doctor`.
 - Don't introduce nested-key syntax via `canopy config augments.preflight_cmd` — that's a future refactor of `cmd_config`. v1 writes TOML directly.
 - Don't alter `[issue_provider]` or `[[repos]]` structural fields from this skill — those are different concerns.