Cloud-SDK extraction — Phase 0: split platform_kubernetes + audit-script CI gate (+ design & plan)

.github/workflows/ci.yml

@@ -394,6 +394,14 @@ jobs:
         run: |
           ! grep -qH "digitalocean/godo" go.mod example/go.mod
 
+  cloud-sdk-audit:
+    name: Cloud-SDK inventory + k8s-backend init() partition audit
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Audit cloud-SDK imports + init() partition
+        run: bash scripts/audit-cloud-symbols.sh --check
+
   aws-sdk-banned:
     name: Verify removed AWS SDK packages are not imported (issue #653)
     runs-on: ubuntu-latest

decisions/0033-add-ctx-to-module-iac-state-store.md

@@ -0,0 +1,28 @@
+# 0033. Add context.Context to module.IaCStateStore mid-extraction
+
+**Status:** Accepted
+**Date:** 2026-05-14
+**Decision-makers:** Jon (operator), autonomous pipeline
+**Related:** docs/plans/2026-05-14-cloud-sdk-extraction.md (PR 6 / Task 15), docs/plans/2026-05-14-cloud-sdk-extraction-design.md, decisions/0031-strict-contracts-ergonomics.md
+
+## Context
+
+The cloud-SDK-extraction plan was scope-locked at 5 PRs / 14 tasks. During PR 3 / Task 7, the new host-side `grpcIaCStateStore` had to hardcode `context.Background()` on every RPC because `module.IaCStateStore`'s 6 methods (`module/iac_state.go:21`) take no `context.Context` — the call sites have no caller context to plumb. Task 7 shipped with a code comment flagging this as a known follow-up. The operator observed that, since the extraction is already rewriting that exact interface boundary, deferring the ctx change means a second cross-cutting PR later that touches the same files again.
+
+Investigation established the blast radius is bounded and entirely within `module/`: the interface + its 7 implementations (`memory`/`fs`/`postgres`/`spaces`/`gcs`/`azure`/`grpc_client`) + the one caller file `module/pipeline_step_iac.go` (whose pipeline steps already hold a `PipelineContext`). The separate, unrelated `interfaces.IaCStateStore` (`interfaces/iac_state.go:14`) already takes `context.Context` on every method and is **not** touched. Adding scope to a locked plan is "intentional friction" per `skills/scope-lock/SKILL.md`; the operator gave explicit approval after reviewing the scoped blast-radius analysis.
+
+## Decision
+
+We will add `ctx context.Context` as the first parameter to all 6 `module.IaCStateStore` methods now, as a new dedicated PR (PR 6 / Task 15) appended to the locked manifest — not deferred, and not folded into PR 3's existing tasks.
+
+Alternatives rejected:
+- **Fold into PR 3's Task 7/8.** Rejected — it stretches those tasks' definitions past their locked scope and erodes per-PR review/revert granularity; the change is cohesive enough to stand alone.
+- **Keep deferred (the original plan's posture).** Rejected by the operator — doing it post-extraction is a second cross-cutting PR re-touching the same files, and the Phase B/C/D plugin-side backend implementations would otherwise be built against a ctx-less interface and need their own follow-up retrofit.
+
+## Consequences
+
+- **Easier:** `grpcIaCStateStore` plumbs the caller's real context; `iacStateBackendServer` forwards its gRPC-received context into the store instead of discarding it; cancellation/deadline propagation works through the new contract. Phase B/C/D plugin backends are written ctx-ful from the start.
+- **Easier:** removes the `context.Background()` wart and its apologetic comment from Task 7's code.
+- **Harder / cost:** the locked plan grows to 6 PRs / 15 tasks; the manifest is amended, re-aligned, and re-locked (a new lock hash). PR 6 must land before PR 3 is finalized so Task 7's `grpcIaCStateStore` is amended in place rather than shipped ctx-less then re-touched.
+- **New constraint:** every future `module.IaCStateStore` implementation (the four cloud plugins in Phase B/C/D) must accept and honor `ctx`. This is the intended outcome but is now a hard contract, not a nicety.
+- **Bounded undo cost:** reverting is a single-PR revert of a mechanical signature widening; no data-format or wire-contract change is involved (the `IaCStateBackend` proto already carries gRPC's context implicitly).

decisions/0034-cross-repo-agent-operation-for-plugin-prs.md

@@ -0,0 +1,30 @@
+# 0034. Plugin-repo PRs run as autonomous cross-repo agent work, not human gates
+
+**Status:** Accepted
+**Date:** 2026-05-14
+**Decision-makers:** Jon (operator), autonomous pipeline
+**Related:** docs/plans/2026-05-14-cloud-sdk-extraction.md (PR 4), docs/plans/2026-05-14-cloud-sdk-extraction-design.md, decisions/0033-add-ctx-to-module-iac-state-store.md
+
+## Context
+
+The cloud-SDK-extraction plan's PR 4 (`workflow-plugin-azure` implements the `azure_blob` IaCStateBackend) lands in a *different git repository* than the worktree the subagent-driven pipeline runs in. The plan originally marked PR 4 a "HUMAN-GATE": the pipeline would pause and hand Tasks 11–12 to a human operator, on the conservative assumption that worktree-scoped subagents should not autonomously branch/commit/push/PR/tag in a second repo.
+
+The operator rejected that framing. The whole extraction effort is inherently multi-repo — Phases B/C/D each touch `workflow-plugin-{aws,gcp,digitalocean}`, and the design already assumes "one PR per affected plugin." Treating every plugin PR as a human gate would make the autonomous pipeline barely autonomous. The operator's directive: agents should operate in those other repo contexts directly; the real requirement is not a human gate but **prompt clarity** — each cross-repo agent must be told unambiguously which repository it is working in.
+
+## Decision
+
+We will treat plugin-repo PRs (PR 4 here, and the analogous plugin PRs in the deferred B/C/D plan) as **normal autonomous cross-repo agent work**, not human gates. The plan's PR 4 row, its "human-action gate" paragraph, and the executor notes are updated accordingly.
+
+The replacement requirement: every agent dispatched to do cross-repo work MUST receive, explicitly in its prompt, (a) the absolute path of the repository it operates in, (b) a statement that it is a *different* repo than the worktree, and (c) which repo each file path belongs to. The push + PR-creation steps still follow normal review discipline (feature branch, PR for review — never direct-to-default-branch), and a published release tag is still a deliberate, called-out step — but none of that requires pausing for a human to *perform* the work.
+
+Alternatives rejected:
+- **Keep the human gate.** Rejected by the operator — it defeats the autonomous pipeline for an inherently multi-repo effort.
+- **A single mega-worktree spanning all repos.** Rejected — the repos are independently versioned and released; conflating them breaks per-repo PR/review/tag boundaries.
+
+## Consequences
+
+- **Easier:** PR 4 (and B/C/D plugin PRs) execute autonomously; no operator hand-off mid-pipeline. The pipeline is genuinely autonomous end-to-end.
+- **Easier:** consistent pattern for every plugin repo across all phases — no per-PR "is this a gate?" judgment.
+- **Harder / risk:** an agent operating in the wrong repo is now a live failure mode. Mitigated by the mandatory prompt-clarity requirement (absolute repo path + explicit "different repo" callout in every cross-repo dispatch) and by the orchestrator verifying `git -C <repo> log` after cross-repo commits.
+- **New constraint:** cross-repo agent prompts have a fixed preamble obligation (repo path + scope). The orchestrator owns enforcing it.
+- **Unchanged:** push/PR still go through review; a published plugin release tag is still an explicit, deliberate step (PR 5 depends on PR 4's tag) — autonomy here means the agent *performs* the steps, not that review/release discipline is skipped.