feat: ship a Kiro power that drives this accelerator

.github/labeler.yml

@@ -0,0 +1,35 @@
+# Configuration for .github/workflows/label.yml (actions/labeler@v7).
+#
+# The workflow has run since it was added and has never succeeded, because this
+# file did not exist. actions/labeler resolves its config with
+# `ref: github.context.sha`, which under `pull_request_target` is the base
+# branch commit — so the file has to be on the default branch to be found. A
+# contributor cannot supply it from a pull request branch.
+#
+# Labels below are limited to ones that already exist in this repository.
+# actions/labeler creates missing labels implicitly with an arbitrary colour, so
+# adding a new name here has a side effect outside this file.
+
+documentation:
+  - changed-files:
+      - any-glob-to-any-file:
+          - 'docs/**'
+          - '**/*.md'
+
+python:
+  - changed-files:
+      - any-glob-to-any-file:
+          - '**/*.py'
+          - 'requirements.txt'
+
+github_actions:
+  - changed-files:
+      - any-glob-to-any-file:
+          - '.github/workflows/**'
+          - '.github/labeler.yml'
+
+dependencies:
+  - changed-files:
+      - any-glob-to-any-file:
+          - 'requirements.txt'
+          - '**/package.json'

.github/workflows/shell-checks.yml

@@ -48,3 +48,12 @@ jobs:
 
       - name: Workshop module flow (maps, explains, verifies, ordering)
         run: bash scripts/check-workshop-flow.sh
+
+      # The Kiro power in kiro/ documents this repo's commands, flags and module
+      # sequences. It ships here so that a rename breaks the build rather than
+      # quietly breaking someone's session: this gate resolves every file:line
+      # citation against the tree, and checks the profile sequences against
+      # PROFILE_MODULES and each cited --flag against the script it is used with.
+      # Stdlib only, no AWS, no network.
+      - name: Kiro power matches the source it documents
+        run: bash scripts/check-kiro-power.sh

README.md

@@ -28,6 +28,10 @@ Use this five-step path to get from a starting point to a working deployment.
 > When something breaks, [`docs/TROUBLESHOOTING.md`](docs/TROUBLESHOOTING.md) is
 > organised by symptom.
 
+> **Using Kiro?** This repository ships a [Kiro power](#drive-it-with-kiro) that
+> can walk any of these five steps with you — picking a profile, deploying and
+> verifying a module at a time, and diagnosing what failed.
+
 
 ## Choose Your Starting Point
 
@@ -134,6 +138,46 @@ python3 -m http.server 8888 -d dashboard/public
 
 ![AgentCore deployment dashboard monitor tab](docs/dashboard-monitor.png)
 
+## Drive It with Kiro
+
+[`kiro/agentcore-enterprise-platform/`](kiro/agentcore-enterprise-platform) is a
+[Kiro](https://kiro.dev) **power**: the operational knowledge about *this* repository,
+packaged so an agent can drive it rather than just describe it. Ask it which profile
+fits your situation, what a module actually deploys, why module 6 has been silent for
+seven minutes, what is billing right now, or hand it the deployment and approve one
+command at a time.
+
+Powers are added through the Kiro UI. **Powers panel → Add Custom Power → Local
+Directory**, then paste the path this prints — the power directory itself, not the
+repository root:
+
+```bash
+echo "$(git rev-parse --show-toplevel)/kiro/agentcore-enterprise-platform"
+```
+
+`POWER.md` routes; the detail sits in 14 `steering/` files that load only when the
+question calls for them. Six of those are **runbooks** — deploy the platform, deploy
+one module, verify, recover a failed deploy, audit cost, tear down — ordered
+procedures with a verify gate after each step and explicit halt conditions, for when
+you want the deployment run rather than explained. They spend real money in a real
+account, so anything that creates, changes, deletes, or bills is proposed one command
+at a time and waits for you.
+
+> **It is blunt about this repository on purpose.** Security controls are opt-in and
+> default off; a `-security` stack at `CREATE_COMPLETE` means the resources exist, not
+> that anything is enforced; `enable_networking=true` is not an air-gapped VPC; Cedar
+> ships in `LOG_ONLY`. The power says so, in the same terms as
+> [`docs/SECURITY_CONTROLS.md`](docs/SECURITY_CONTROLS.md), because a facilitator who
+> overstates the posture loses the room in the first security question.
+
+The power ships here rather than in a repository of its own so that its claims stay
+tied to the code: `scripts/check-kiro-power.sh` runs in CI and fails the build when a
+cited `file:line` no longer resolves, a restated profile sequence drifts from
+`PROFILE_MODULES` in `scripts/deploy.sh`, or a cited `--flag` does not exist in the
+script it is used with. A rename breaks the build instead of quietly breaking
+someone's session. [`kiro/README.md`](kiro/README.md) covers the layout and how to
+change it.
+
 ## Clean Up
 
 Destroy resources when you no longer need them

kiro/README.md

@@ -0,0 +1,81 @@
+# Kiro power for this accelerator
+
+[`agentcore-enterprise-platform/`](agentcore-enterprise-platform) is a
+[Kiro](https://kiro.dev) **power**: operational knowledge about *this* repository,
+packaged so an agent can drive it — pick a deployment profile, deploy and verify a
+module, diagnose a failure, audit what is billing, tear it down.
+
+It carries what a checkout does not: which profile fits a given situation, what
+each module actually deploys versus what its title suggests, which command proves
+a layer works, why module 6 goes silent for seven minutes, which flags are sharp,
+and which security controls are enforced rather than merely declared.
+
+## Install it
+
+Powers are added through the Kiro UI; there is no CLI for it.
+
+**Powers panel → Add Custom Power → Local Directory**, then paste the absolute
+path of the `agentcore-enterprise-platform/` directory inside your clone — not the
+repository root, and not this `kiro/` directory:
+
+```bash
+echo "$(git rev-parse --show-toplevel)/kiro/agentcore-enterprise-platform"
+```
+
+After pulling a change to these files: **Powers panel → the power → Check for
+Updates → Update Power**.
+
+The power bundles two MCP servers (`mcp.json`): the AgentCore MCP server, which
+needs [uv](https://docs.astral.sh/uv/) on `PATH` for `uvx`, and the AWS Knowledge
+server over HTTP. Nothing in either is pre-approved — Kiro strips `autoApprove`
+from a power's `mcp.json` on load, so a power cannot grant itself auto-approval.
+Approving the read-only tools and leaving anything that creates, updates, deletes
+or invokes on manual confirmation is the posture to aim for.
+
+## Layout, and why it is this exact shape
+
+```
+agentcore-enterprise-platform/
+  POWER.md          router: profile picker, module map, the sharp edges, steering index
+  mcp.json          MCP servers only, no display metadata
+  steering/         the detail — loaded on demand, one file per question shape
+    runbook-*.md      six procedures, for driving rather than explaining
+```
+
+Kiro's power installer copies a fixed allowlist — `POWER.md`, `mcp.json`, and
+`.md` files under `steering/` — and its validator **rejects** a power directory
+containing anything else that looks like a script, an archive, a credential, or a
+**hidden file at any depth**. So `.DS_Store` landing in here makes the power fail
+to install with an error that does not mention `.DS_Store`. That is why this
+README lives one level up, outside the power directory, and why
+`scripts/check-kiro-power.sh` checks installability rather than trusting it.
+
+It is also why the six runbooks are `steering/runbook-*.md` rather than the
+`skills/<name>/SKILL.md` layout Kiro's skill *reader* expects: `skills/` is not on
+the installer's allowlist, so an installed power has no `skills/` directory and
+every runbook read fails. `POWER.md` routes to the filenames that actually exist.
+
+## Changing it
+
+Run the gate before you commit:
+
+```bash
+bash scripts/check-kiro-power.sh
+```
+
+It runs in CI on every pull request and makes no AWS calls and no network calls.
+Beyond the power format, it checks the claims against the tree they are shipped
+with: every `file:line` citation resolves and is in bounds, every restatement of a
+profile's module sequence matches `PROFILE_MODULES` in `scripts/deploy.sh`, and
+every `--flag` cited next to one of this repo's scripts exists in that script.
+
+That coupling is the point of shipping the power here rather than in a repository
+of its own. A hallucinated flag reads exactly like a real one and only fails in
+front of a user, and a renamed flag is indistinguishable from a hallucinated one
+a month later. Keeping these files next to the code means a rename breaks the
+build instead of quietly breaking someone's session.
+
+**The one rule that matters most: every claim must be verifiable in this
+repository's source.** Prefer a real run over a reading — the timings and error
+strings in `steering/troubleshooting.md` came from actual deployments. If you
+cannot confirm something, cut it rather than hedging it.