@rasensio/aidlc-content 1.67.0 → 1.73.1

package/docs/hygiene-and-compliance.md

@@ -55,6 +55,35 @@ that acts on a record's *absence*. So the two provenance-dependent migrations co
 `complianceSectionState()` first and decline to run at all when the section is present but
 unreadable, rather than concluding a live pack was uninstalled.
 
+### Why a mechanical control's pattern is tested in the direction it is wrong
+
+A control with `check_kind: mechanical` carries a `pattern`, and `aidlc compliance check` fails the
+control when any added line matches it. That makes the pattern the whole control: there is no prose
+for an agent to interpret and no second opinion.
+
+The plain-HTTP control shipped for months with `http://(?!localhost|127\.0\.0\.1|\[::1\])`, and its
+test asserted the two things the pattern got right — plain HTTP to `api.example.com` is flagged,
+`http://localhost:3000` is not. Nothing asked about a host that merely *starts* with a loopback
+name, and the lookahead had no host boundary, so `http://localhost-api.corp.net` and
+`http://localhost@evil.example.com` passed a check whose report said it ran. A second pack then
+copied the pattern as "already tested", and copied the blind spot with it.
+
+Two rules came out of that, and they generalise to any pattern-backed control:
+
+- **A pattern's test covers the cases it was written from, which are the cases its author already
+  had right.** The useful cases are the ones that distinguish a correct pattern from a plausible
+  one — a near miss on each side of the boundary. Pin the superseded pattern in the test and assert
+  that every new case was one it got wrong; otherwise a case that passes under both patterns reads
+  as coverage and is not.
+- **One pattern in two packs is one pattern.** Two controls sharing a rule share the string, and a
+  test asserts they are equal. Divergence then fails a test rather than becoming two patterns
+  nobody compares.
+
+The false-positive side is a deliberate trade. The pattern now flags `localhost.localdomain` and
+`127.0.0.1.nip.io`, which really are loopback, because sparing them would need a host parser rather
+than a regular expression — and a control that misses a real host is worse than one that asks about
+an unusual alias.
+
 ## How to use it
 
 ```
@@ -104,7 +133,8 @@ entry's own recorded hash matches what is on disk. The record is tracked, so a c
 it. The hash used to be looked up by file *basename*, so a second entry named `victim.md` could
 vouch for `../../victim.md` and get a file outside the project deleted (security-review-findings).
 
-`compliance list` shows packs available and installed. `soc2` ships with the framework. `check` returns
+`compliance list` shows packs available and installed. Two ship with the framework: `soc2` and
+`iso27001` (ISO/IEC 27001:2022, Annex A only). `check` returns
 the controls applying to the current phase, each with its requirement, where to look, and its fail
 condition.
 
@@ -128,7 +158,8 @@ and read what it says the second time. Steady-state bugs are invisible on the fi
 - `packages/cli/src/doctor` — the checks and repairs. `migrations` holds the one-off repairs, including
   the nested-`.gitignore` coverage fix.
 - `packages/cli/src/compliance` — pack loading, control evaluation, and the evidence report.
-- `packages/content/packs` — the shipped packs; `soc2` is the only one today.
+- `packages/content/packs` — the shipped packs, `soc2` and `iso27001`. A new directory there is a new
+  pack; nothing else registers it.
 - `packages/content/skills/80-review.md` — where the compliance findings stream is specified, including
   the two-places rule for every applicable control.
 - `packages/cli/src/operational/redact.ts` — redaction used when repo state is turned into something

package/docs/index.yaml

@@ -91,7 +91,7 @@ entries:
     title: Skills and platforms
     file: skills-and-platforms.md
     source: packages/cli/src/compile
-    commands: [add, update, docs, explain]
+    commands: [add, update, docs, explain, hook]
 
   - id: hygiene-and-compliance
     kind: topic
@@ -113,3 +113,10 @@ historical_paths:
       `knowledge-stale-sources` check: 15 graph entities described it for 17 days, and
       neither page can make that point without writing the path that no longer resolves.
       The entries were removed by stale-graph-entries; the story is what stays.
+  - path: .codex/hooks.json
+    reason: >-
+      Codex's project hook file, named in skills-and-platforms.md as where the Codex
+      session-start hook goes. It is written only when a user agrees to it
+      (hooks-carry-lifecycle-state/AC-18, AC-20), and nobody has agreed for this
+      repository, so it does not exist here — an unattended session cannot give that
+      consent on the user's behalf.

package/docs/knowledge-graph.md

@@ -119,3 +119,34 @@ One implementation lesson worth carrying: a "preserve this unchanged" path that
 serializer does not preserve anything. Rebuilding the index must copy bytes, not re-emit parsed
 structures, or comment formatting and key order drift on every rebuild — 829 lines of diff versus 108
 on real data.
+
+## Why the index checks whether it is current
+
+`index.db` is a cache, and for two months it was rebuilt only when it was missing or empty. That
+covers the index you have never built. It does not cover the one you built in September and have been
+pulling other people's commits into ever since — so facts arriving by `git pull`, a merge, a branch
+switch or another worktree's commit never reached it, and `aidlc knowledge query` answered from
+whatever state the file was first built in.
+
+The tell was in `CLAUDE.md`. The `# Codebase Knowledge` block is generated from the index, so two
+checkouts with differently-stale caches generated two different blocks, and one entry flipped between
+its current and stale text ten times in a month. Six instances hit it, and all six reverted it by hand
+as "unrelated churn" — which is the part worth remembering. A wrong answer that looks like noise gets
+filed as noise. Nobody reported it as a defect until a retrospective counted the reverts.
+
+So the index now records a stat hash of the sources it was built from — path, size and mtime, never
+contents — and rebuilds whenever that record and the disk disagree. Three things about it are
+deliberate:
+
+- **Stat, not content.** Reading every file to decide whether to read every file buys nothing:
+  parsing this project's 62 source files costs 185ms and stat-ing them costs 1ms.
+- **The hash is taken before the sources are read**, not after, so a file that changes mid-read leaves
+  the record stale and the next open rebuilds. Every failure mode is pointed the same way: a missing
+  or unreadable or unparseable fingerprint all mean *rebuild*. Forgetting to record one costs an extra
+  rebuild; forgetting to check one costs a month of wrong facts, and that asymmetry decides every
+  default in the design — including why `compact` and the write paths deliberately record nothing.
+- **It lives inside `index.db`**, not in a sidecar, so `rm index.db` can never leave behind a
+  fingerprint claiming the cache is fresh. Deleting the file stays a complete repair.
+
+The same shape guards the coverage cache in `src/traceability/cache.ts`, which is where the pattern
+came from.

package/docs/roadmap.md

@@ -168,6 +168,30 @@ Each item goes through these steps:
    error within 30 seconds of launch parks the item with `agent failed to launch (exit <code>):`
    and the first line it printed, so a flag the agent no longer accepts names itself instead of
    reading as a failed build.
+
+   **The agent reports a typed result.** With one of the Claude Code or Codex presets, autopilot
+   asks the agent how it ended: Claude Code runs with `--output-format json` and an outcome schema,
+   Codex with `--json`, `--output-schema` and `-o`, and the agent finishes by reporting `shipped`,
+   `paused`, `parked` or `blocked`, with its reason. When the agent exits, that result decides what
+   happens next before the instance's phase does, so a parked item says why it stopped — the cost
+   cap, a turn limit, a failed session, or the agent's own reason, followed by the first tool call
+   the scoped preset refused. Each session also leaves a summary in the item's log: how it ended,
+   what it cost, its turns, its session id, and each refused tool call and failed command.
+
+   **A stopped session is resumed once.** An item stopped by a dropped connection is resumed with
+   its own session id at the next pass. One stopped by a session limit waits for the reset time
+   its message names — an hour when it names none, parked at once when the reset is more than six
+   hours away — launches no other agent meanwhile, and is then resumed once. Stopping the same way
+   again parks it with the session id. A command you typed yourself is launched exactly as you
+   wrote it and handled as before.
+
+   **A session that ended before the release boundary is resumed once too.** Under `claude -p`
+   the end of the agent's turn is the end of its session, so an agent that ends its turn to wait
+   for its test suite is gone, and the suite with it. When a session ends short of the release
+   boundary with no outcome, `blocked`, or a `shipped` or `paused` its phase does not bear out,
+   it is resumed at the next pass, with a prompt to run the command again and wait for it inside
+   the turn. A second early ending parks the item with the session id. Every resume releases the
+   instance's claim first, so the resumed session can take it.
 3. **Your review, after each paused phase.** When a phase in `pause_after` is complete and
    unapproved, the item waits as `awaiting-review` — not parked. Read the artifact in the item's
    worktree, then `aidlc autopilot approve <instance>`; the next pass waits at the next paused
@@ -186,9 +210,16 @@ Each item goes through these steps:
 6. **Up to date with main**, for an item autopilot merges itself. Before merging, it merges
    `origin/main` into the branch in the
    item's worktree — locally, so the repository's `merge=union` rules apply — pushes, and waits for
-   CI on the new head. A conflict goes back to the item's agent to resolve, twice at most, then the
-   item is parked. A pull request with no checks that GitHub reports as conflicting is handled the
-   same way: GitHub runs no checks on a conflicting PR, so waiting for them would wait forever.
+   CI on the new head. Just before that merge it commits the worktree's two cost ledgers,
+   `.aidlc/cost/unattributed.ndjson` and the instance's `costs.ndjson`, and nothing else: the cost
+   hook keeps writing to them after the agent's last commit, and git refuses to merge over an
+   uncommitted change to a file main also changed. A conflict — a merge that leaves unmerged
+   files — goes back to the item's agent to resolve, twice at most, then the item is parked. A merge
+   git refuses without one, because some other local change would be overwritten, is not a
+   conflict: it halts the queue as a failed update with git's message, and `aidlc autopilot run`
+   resumes it once you have dealt with the change. A pull request with no checks that GitHub reports
+   as conflicting is handled the same way: GitHub runs no checks on a conflicting PR, so waiting for
+   them would wait forever.
 7. **Merge and release**, one at a time, never while a release workflow is running: merge the exact
    commit CI passed (`--match-head-commit`), pull `main`, run the release step when the item's stop
    is `release`, then `aidlc transition` to close the instance. A failure halts the queue. Running
@@ -209,7 +240,12 @@ six questions on its own. Each is a list with one choice marked recommended:
   it is never picked for you: with no terminal, setup needs `--agent <preset>` or
   `--non-interactive`.
 - **How many items build at once** — two (recommended) or one.
-- **A cost cap per item** — an item past it is stopped and parked.
+- **A cost cap per item** — an item past it is stopped and parked. Claude Code is given the cap as
+  its budget (`--max-budget-usd`), less what the item already spent and a 10% margin, because it
+  checks its budget only after each turn. Codex has no budget flag, so autopilot prices its token
+  usage as it runs and stops it at the cap less the same margin. That needs a rate for its model
+  under `cost.rates` in `.aidlc/config.yaml`; without one autopilot says so once, and only
+  `aidlc cost` holds the run to the cap.
 - **Which phases to pause after for your review** — after requirements and design (recommended),
   after design only, or no pauses. These are the two phases whose output decides the shape of the
   code.

package/docs/skills-and-platforms.md

@@ -93,6 +93,59 @@ reviewer cannot write, it replies with its findings files and the session that s
 unchanged. Claude Code reads `.claude/agents/` at session start, so an `update` that adds the agent
 takes effect in the next session.
 
+**Skill metadata** is the other thing a skill declares for the harnesses rather than for the reader.
+Four optional keys sit in a content skill's frontmatter, and each adapter translates them; none of
+them reaches the shared copy under `.aidlc/skills/`, and a bad value fails the parse rather than
+quietly meaning the default.
+
+- `arguments` — a one-line hint, such as `<instance> <artifact>` on the review. Claude Code shows it
+  as `argument-hint` when you type `/aidlc-review`.
+- `invocation` — who may start the skill. `auto`: the model, on a matching request. `routed`: reached
+  through another skill or by name. `user`: only you, by name. On Claude Code `user` becomes
+  `disable-model-invocation: true`, which the two autopilot skills carry so a loose sentence never
+  launches background work; `routed` changes nothing there, because a description match is how Claude
+  Code routes. On Codex, `agents/openai.yaml` beside each skill sets `allow_implicit_invocation`, true
+  only for `aidlc` and `aidlc-continue`. That keeps Codex's listing — 2% of the context window, with
+  descriptions shortened first when over it — to two skills. `aidlc-continue` stays implicit because
+  autopilot names it in plain words, and the sub-agents line one-agent-per-task depends on is in the
+  Codex skill file only, not in the shared copy.
+- `tier` — `reasoning` (ideation, requirements, design), `standard` (implementation, maintenance) or
+  `mechanical` (testing, deployment). See below.
+- `activation: none` — the skill takes none of its phase's capability lines. The overview is declared
+  `phase: ideation`, so before this it opened with "enter plan mode" although it writes nothing.
+  Getting-started, first-activation, the review and the two autopilot skills declare it too.
+  `aidlc-continue` must not: it is the route an unattended run takes into implementation.
+
+A Claude Code shim also gets `when_to_use` from the skill's `trigger`. Both managed blocks — the one in
+`CLAUDE.md` and the one in `AGENTS.md` — say where to read a skill the agent is not offered, so the
+entry skill's "follow the aidlc-autopilot skill" still works when the model cannot pick that skill
+itself.
+
+There is no tool profile, on purpose. Claude Code's `disallowed-tools` lasts until your next message,
+and an unattended run is a single message, so a read-only skill loaded anywhere in it would take Edit
+and Write away for the rest of the run. The review, the one skill that must not write, already gets
+that from its agent.
+
+**Model and effort per tier** are off until you set them, in `.aidlc/config.yaml`:
+
+```yaml
+skill_tiers:
+  mechanical:
+    model: sonnet
+    effort: low
+  reasoning:
+    effort: high
+```
+
+Each value is written as `model` or `effort` into the Claude Code shims of the skills in that tier;
+`inherit`, or no entry, writes nothing. `effort` takes `low`, `medium`, `high`, `xhigh` or `max`. A
+`model` must be one name of letters, digits and `. _ - : / [ ]` — a value that is not is warned about and
+left out, which is also what stops a config value from adding a header line of its own. Two limits are
+Claude Code's, not AIDLC's. The override lasts until your next message, and it applies only when the
+phase skill itself is invoked, as `/aidlc-testing`; `aidlc-continue` reads a phase's body directly, so
+an unattended run is not routed. Codex gets neither value: it would need a custom agent or a profile per
+tier, which is not built.
+
 Those files also carry a **top-level `questions:` key**, outside the phase-keyed `capabilities:` map, and
 the reason it sits outside is not cosmetic. The shared capability resolution returns exactly one
 activation string per phase, and three platforms already occupy `requirements` and `design` — the two
@@ -122,6 +175,32 @@ an adapter to emit a file, check which of those two shapes you have first.
 If you are adding an operational skill of your own, reuse this seam rather than writing platform files
 directly.
 
+**Lifecycle hooks** carry state the skills cannot: where the agent is after a session was compacted,
+cleared or resumed. `aidlc hook session-start` prints at most three lines — the instance claimed in
+this checkout, its phase and its next step, the lowest open task in implementation — and nothing
+when nothing is claimed here. A claim counts when it was recorded from this working directory, stale
+or not: claims renew only at phase transitions, and one phase outlasts the 60-minute window, so a
+live-only rule would go quiet on a compaction deep into implementation, the case the hook is for. It
+reads no stdin, writes nothing, and reads only the claimed instance's files — `aidlc status --json`
+reads every instance and ledger and is far too slow for a hook. `aidlc init` installs it for Claude
+Code in `.claude/settings.json`, beside the cost hooks, under its own `#aidlc-lifecycle-hook` marker so
+neither installer counts or removes the other's entries; existing projects run `aidlc hook install`.
+Both hooks run through the cost-capture shim, never a `PATH` lookup. For Codex, init asks first,
+defaulting to no, and writes the project's `.codex/hooks.json` only on a yes (or on
+`aidlc hook install --platform codex`): Codex runs a project hook only after the user trusts it with
+`/hooks`, keyed on its content, and AIDLC never writes that trust — which is also why install rewrites
+the file only when its text would change.
+
+**The phase guard** is the opt-in other half: `aidlc hook install --guard` adds a `PreToolUse` hook on
+`Edit`, `Write`, `MultiEdit` and `NotebookEdit` that **asks** before a project file outside `.aidlc/`
+is edited while the claimed instance is in ideation, requirements or design. It never denies and never
+allows, and on anything it cannot read it says nothing, so the normal permission flow decides. That is
+the reviewer guard's contract inverted on purpose: the reviewer guard is a security boundary and fails
+closed; this one enforces a process rule, and a hook that blocks legitimate work is the failure it
+must not have. Files written through `Bash` are not seen — a guardrail, not a boundary. Codex has no
+guard, because its `PreToolUse` can deny or rewrite a call but not ask. `aidlc hook remove --guard`
+takes it away again.
+
 **Unattended mode.** Every skill assumes a person is there to answer. With `AIDLC_UNATTENDED=1`, an
 agent follows `.aidlc/resources/rules/unattended.md` instead: each place a skill would ask, wait or
 confirm has one written outcome — take the named default and log it to the instance's
@@ -141,10 +220,16 @@ would be a cost every future change pays.
   through `90-retrospective.md`). This is the only place instructions are authored.
 - `packages/content/capabilities` — per-platform capability declarations, plus each platform's
   `questions:` rendering.
+- `packages/cli/src/compile/skill-metadata.ts` — the allowed values of the four skill metadata keys
+  and the `skill_tiers` check, in one place so the parser, the adapters and the config cannot disagree.
 - `packages/cli/src/compile/question-rendering.ts` — emits `.aidlc/resources/questions/rendering.md`, the
   one file holding how each configured platform puts a question in front of the user. The protocol it
   serves is in `packages/content/resources/rules/question-protocol.md` and names no platform tool
   anywhere; that split is what stops the question shape from being written for one platform's UI.
+- `packages/cli/src/hooks` — the lifecycle hooks: `lifecycle-context.ts` reads claims and the claimed
+  instance's state without writing (it does not open the claim store, which creates directories and
+  migrates legacy claims), `guard.ts` decides the phase guard's `ask`, and `install.ts` merges both
+  platforms' hook files. `commands/hook.ts` is the `aidlc hook` command.
 - `packages/content/resources/rules` — the six rules skills send readers to (the context rule, the
   always-read rule, the constitution rule, the Question Protocol, Creating an Instance, Lifecycle or
   Skill?), one file each. `packages/cli/src/compile/rules.ts` emits them to `.aidlc/resources/rules/`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.67.0",
+  "version": "1.73.1",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/packs/iso27001/controls.yaml

@@ -0,0 +1,574 @@
+# ISO/IEC 27001:2022 — Annex A controls only.
+#
+# Ids are written A<theme>.<n>: `A8.25` is Annex A control 8.25. The pack validator
+# accepts that shape and rejects `A.8.25` and `8.25`, and the A prefix keeps every id
+# distinct from the SOC 2 pack's CC ids, which matters because `aidlc compliance
+# check` keys agent outcomes by control id across all installed packs
+# (iso-27001-pack/AC-4, AC-24).
+#
+# Clauses 4-10 — the information security management system itself — are not
+# controls and are not listed here. Certification is of that system, and nothing a
+# code tool reads can speak to it. The constraint layer says so.
+#
+# The text below paraphrases the standard in this pack's own words and cites control
+# numbers only. ISO's text is copyrighted; obtain the standard from ISO.
+#
+# `kind` says what the AIDLC artifact trail can establish:
+#
+#   evidenced     the trail genuinely demonstrates the control
+#   checked-only  the control operates over a running system, so no document
+#                 evidences it; the pack supplies a fail condition an agent
+#                 applies, and the trail records only that the check happened
+#
+# `check_kind` says who applies the fail condition: `mechanical` controls carry a
+# pattern the diff check evaluates itself, `agent` controls need a review session.
+#
+# Five controls are `evidenced`. Seven are `checked-only`. Eighty-one Annex A
+# controls are not covered at all, each listed below with its reason.
+#
+# `references` points at the guidance layer whose rule a control restates, so the
+# duplication is traceable. The pack's own constraint layer does not restate those
+# rules.
+
+controls:
+  # -------------------------------------------------------------------------
+  # Evidenced: the lifecycle trail is real evidence for these controls. Most of
+  # them sit in the 8.25-8.33 run of software-development controls.
+  # -------------------------------------------------------------------------
+  - id: A5.8
+    kind: evidenced
+    check_kind: agent
+    severity: major
+    phases:
+      - requirements
+      - design
+    requires: >-
+      Information security is built into how projects are run, whatever kind of
+      project it is: security risks are identified early and handled as part of the
+      project's own work rather than afterwards.
+    look_at: >-
+      design.md for the security considerations of the change — the risks it names
+      and how each is handled — and requirements.md for the non-functional security
+      requirements the design answers to.
+    fails_when: >-
+      design.md is absent, or names no security consideration for the change: neither
+      a risk with how it is handled, nor an explicit statement that the change carries
+      none.
+    evidence_artifact: design.md
+
+  - id: A8.25
+    kind: evidenced
+    check_kind: agent
+    severity: major
+    phases:
+      - requirements
+      - design
+      - implementation
+      - testing
+      - deployment
+    requires: >-
+      Rules for developing software and systems securely are set and are actually
+      applied to the development work.
+    look_at: >-
+      transitions.log for the recorded passage of the change through each lifecycle
+      phase its template requires, and the guidance layers each phase read — the
+      secure-defaults layer above all — as the development rules applied.
+    fails_when: >-
+      The instance has no transitions.log, or the log shows the change skipping a
+      phase its template requires, so the change did not pass through the defined
+      development lifecycle.
+    evidence_artifact: transitions.log
+
+  - id: A8.26
+    kind: evidenced
+    check_kind: agent
+    severity: major
+    phases:
+      - requirements
+      - design
+    requires: >-
+      The security requirements of an application are identified, specified and
+      approved when it is developed or acquired.
+    look_at: >-
+      requirements.md: the acceptance criteria and the non-functional security
+      section, read against what the change handles — sensitive data,
+      authentication, access control, external input.
+    fails_when: >-
+      A change that handles sensitive data, authentication or access control reaches
+      design with no acceptance criterion in requirements.md stating the security
+      requirement it must meet.
+    evidence_artifact: requirements.md
+
+  - id: A8.29
+    kind: evidenced
+    check_kind: agent
+    severity: major
+    phases:
+      - testing
+    requires: >-
+      Security testing is defined and carried out as part of the development
+      lifecycle, before a change is accepted.
+    look_at: >-
+      test-results.md for the outcome of the testing phase, and the tests that
+      reference each security acceptance criterion in requirements.md.
+    fails_when: >-
+      test-results.md is absent or names no outcome, or a security acceptance
+      criterion in requirements.md has no test referencing it.
+    evidence_artifact: test-results.md
+
+  - id: A8.32
+    kind: evidenced
+    check_kind: agent
+    severity: critical
+    phases:
+      - requirements
+      - design
+      - implementation
+      - testing
+      - deployment
+    requires: >-
+      Changes to information processing facilities and systems go through change
+      management: each is planned, assessed for impact, authorised, tested and
+      accepted before release, with a way back if it fails.
+    look_at: >-
+      requirements.md for numbered acceptance criteria authorising the change;
+      design.md for what the change touches; tasks.md for the link from each task to
+      its criteria; test-results.md for the test outcome; transitions.log for the
+      recorded phase progression; and deployment-record.md for the release and its
+      rollback.
+    fails_when: >-
+      A change reached deployment without each of these on record: numbered criteria
+      in requirements.md, a design.md naming what the change touches, a
+      test-results.md naming an outcome, and a deployment-record.md naming what
+      shipped and how to roll it back.
+    evidence_artifact: deployment-record.md
+
+  # -------------------------------------------------------------------------
+  # Checked-only: these operate over a running system or its surroundings. The
+  # pack gives you a fail condition to apply; the trail records that you applied
+  # it, never that the control operates.
+  # -------------------------------------------------------------------------
+  - id: A8.4
+    kind: checked-only
+    check_kind: agent
+    severity: major
+    phases:
+      - implementation
+      - deployment
+    requires: >-
+      Read and write access to source code, development tools and software
+      libraries is managed appropriately.
+    look_at: >-
+      Repository access configuration touched by the change: CI workflow
+      permissions and secret access, code-ownership rules, branch-protection
+      settings, and any token or deploy key the change introduces.
+    fails_when: >-
+      The change widens write access to the repository or its pipelines with no
+      stated reason — a CI job gains write permissions or access to secrets, an
+      ownership rule for a path is removed, or a token with repository write scope is
+      added.
+    references: secure-defaults#least-privilege-and-defense-in-depth
+
+  - id: A8.8
+    kind: checked-only
+    check_kind: agent
+    severity: major
+    phases:
+      - implementation
+      - deployment
+      - maintenance
+    requires: >-
+      Information about technical vulnerabilities in the systems in use is obtained,
+      the organisation's exposure is evaluated, and suitable measures are taken.
+    look_at: >-
+      Dependency manifests and lockfiles in the change, and whether the build or CI
+      runs a vulnerability audit over the dependency set.
+    fails_when: >-
+      A dependency is added without a lockfile entry, a dependency range is left
+      unpinned, or the project runs no dependency vulnerability audit in its build or
+      CI.
+    references: secure-defaults#dependency-security
+
+  - id: A8.9
+    kind: checked-only
+    check_kind: agent
+    severity: major
+    phases:
+      - implementation
+      - deployment
+    requires: >-
+      Configurations of hardware, software, services and networks, security
+      configurations included, are established, documented, implemented, monitored
+      and reviewed.
+    look_at: >-
+      Configuration and infrastructure-as-code changes in the diff: TLS and
+      certificate settings, CORS and security headers, debug and feature flags, and
+      network rules defined as code.
+    fails_when: >-
+      A configuration change relaxes a security setting with no stated reason — TLS
+      verification turned off, a wildcard CORS origin, a security header removed, or
+      debug mode enabled in a production configuration.
+    references: secure-defaults#transport-and-data-protection
+
+  - id: A8.15
+    kind: checked-only
+    check_kind: agent
+    severity: major
+    phases:
+      - implementation
+      - deployment
+      - maintenance
+    requires: >-
+      Logs recording activities, exceptions, faults and other relevant events are
+      produced, stored, protected and analysed.
+    look_at: >-
+      Error handling and logging in the change: whether failures and
+      security-relevant events are recorded with enough context to investigate, and
+      whether anything sensitive is written to a log.
+    fails_when: >-
+      A failure path swallows an error without logging it, a security-relevant event
+      such as a failed authentication or a denied access goes unlogged, or a log
+      statement records a secret or personal data.
+    references: secure-defaults#error-handling-and-logging
+
+  - id: A8.24
+    kind: checked-only
+    check_kind: mechanical
+    severity: major
+    phases:
+      - implementation
+      - deployment
+    requires: >-
+      Rules for the effective use of cryptography, key management included, are
+      defined and implemented.
+    look_at: Network client configuration and request targets in the change.
+    fails_when: >-
+      An added line targets a plain-HTTP URL whose host is not exactly localhost,
+      127.0.0.1 or [::1], so information would be transmitted without transport
+      encryption.
+    # The same string as SOC 2 CC6.7, kept equal by plain-http-pattern.test.ts; the
+    # reasoning for its shape is beside that control.
+    pattern: "[hH][tT][tT][pP]://(?!(?:[lL][oO][cC][aA][lL][hH][oO][sS][tT]|127\\.0\\.0\\.1|\\[::1\\])(?::\\d+)?(?![\\w:@%~-]|\\.[\\w-]))"
+    references: secure-defaults#transport-and-data-protection
+
+  - id: A8.28
+    kind: checked-only
+    check_kind: agent
+    severity: critical
+    phases:
+      - design
+      - implementation
+    requires: >-
+      Secure coding principles are applied when software is developed.
+    look_at: >-
+      Every place external input crosses into the system in the change — request
+      handlers, message consumers, file uploads and any parser reached from them —
+      and any credential handling.
+    fails_when: >-
+      External input reaches a parser, query, filesystem path or command without
+      validation at the boundary, or a credential, key or token appears in source.
+    references: secure-defaults#input-validation
+
+  - id: A8.31
+    kind: checked-only
+    check_kind: agent
+    severity: major
+    phases:
+      - implementation
+      - deployment
+    requires: >-
+      Development, testing and production environments are kept separate and each is
+      secured.
+    look_at: >-
+      Environment configuration, test setup and fixtures in the change: which
+      endpoints, databases and credentials each environment's code and configuration
+      points at.
+    fails_when: >-
+      Development or test code or configuration points at a production endpoint,
+      database or credential, or a production configuration enables a feature meant
+      only for development.
+    references: secure-defaults#secrets-management
+
+# ---------------------------------------------------------------------------
+# Not covered. Eighty-one of the ninety-three Annex A controls.
+#
+#   organizational  a tool that reads code cannot speak to the control: it is
+#                   about the organisation's governance, people, premises or the
+#                   operation of its infrastructure
+#   not-yet-built   a code lifecycle could say something here, and this pack does
+#                   not yet
+#
+# Every theme 7 and theme 8 exclusion carries a note, because `organizational`
+# alone misdescribes a physical or infrastructure control (iso-27001-pack/AC-10).
+# ---------------------------------------------------------------------------
+excluded:
+  # 5 — Organizational controls.
+  - id: A5.1
+    reason: organizational
+  - id: A5.2
+    reason: organizational
+  - id: A5.3
+    reason: not-yet-built
+    note: >-
+      Segregation of duties has a real lifecycle angle. The trail records who wrote a
+      change and who reviewed it, but nothing checks that they are different people,
+      so this pack does not claim it.
+  - id: A5.4
+    reason: organizational
+  - id: A5.5
+    reason: organizational
+  - id: A5.6
+    reason: organizational
+  - id: A5.7
+    reason: organizational
+  - id: A5.9
+    reason: organizational
+  - id: A5.10
+    reason: organizational
+  - id: A5.11
+    reason: organizational
+  - id: A5.12
+    reason: organizational
+  - id: A5.13
+    reason: organizational
+  - id: A5.14
+    reason: organizational
+    note: >-
+      Rules and agreements for transferring information are the organisation's. A
+      plain-HTTP target added in a change is flagged under A8.24, which is one input
+      here, not the control.
+  - id: A5.15
+    reason: organizational
+  - id: A5.16
+    reason: organizational
+  - id: A5.17
+    reason: organizational
+    note: >-
+      Allocating and managing authentication information is the organisation's
+      process. A credential committed to source is flagged under A8.28; that is not
+      this control.
+  - id: A5.18
+    reason: organizational
+  - id: A5.19
+    reason: organizational
+  - id: A5.20
+    reason: organizational
+  - id: A5.21
+    reason: not-yet-built
+    note: >-
+      The ICT supply chain has a real code angle — dependency inventory, lockfiles
+      and vulnerability audit. Those rules exist in the secure-defaults guidance
+      layer and A8.8 checks them, but this pack does not claim them here: a
+      dependency audit is one input to supply-chain risk management, not the control
+      itself.
+  - id: A5.22
+    reason: organizational
+  - id: A5.23
+    reason: organizational
+  - id: A5.24
+    reason: organizational
+  - id: A5.25
+    reason: organizational
+  - id: A5.26
+    reason: organizational
+  - id: A5.27
+    reason: organizational
+  - id: A5.28
+    reason: organizational
+    note: >-
+      This control is about evidence of security events gathered for legal or
+      disciplinary use. The lifecycle trail is a different kind of evidence and does
+      not serve it.
+  - id: A5.29
+    reason: organizational
+  - id: A5.30
+    reason: organizational
+  - id: A5.31
+    reason: organizational
+  - id: A5.32
+    reason: organizational
+  - id: A5.33
+    reason: organizational
+  - id: A5.34
+    reason: organizational
+    note: >-
+      Identifying and meeting privacy obligations is the organisation's. Personal
+      data written to a log is flagged under A8.15, which is one input here, not the
+      control.
+  - id: A5.35
+    reason: organizational
+  - id: A5.36
+    reason: organizational
+  - id: A5.37
+    reason: organizational
+
+  # 6 — People controls. Screening, employment terms, awareness, discipline,
+  # confidentiality, remote working and event reporting are all about people.
+  - id: A6.1
+    reason: organizational
+  - id: A6.2
+    reason: organizational
+  - id: A6.3
+    reason: organizational
+  - id: A6.4
+    reason: organizational
+  - id: A6.5
+    reason: organizational
+  - id: A6.6
+    reason: organizational
+  - id: A6.7
+    reason: organizational
+  - id: A6.8
+    reason: organizational
+
+  # 7 — Physical controls.
+  - id: A7.1
+    reason: organizational
+    note: Physical security of premises is outside a code tool's reach entirely.
+  - id: A7.2
+    reason: organizational
+    note: Physical entry to premises is outside a code tool's reach entirely.
+  - id: A7.3
+    reason: organizational
+    note: Securing offices, rooms and facilities is outside a code tool's reach entirely.
+  - id: A7.4
+    reason: organizational
+    note: Physical security monitoring is outside a code tool's reach entirely.
+  - id: A7.5
+    reason: organizational
+    note: Protection against physical and environmental threats is outside a code tool's reach entirely.
+  - id: A7.6
+    reason: organizational
+    note: Working in secure areas is outside a code tool's reach entirely.
+  - id: A7.7
+    reason: organizational
+    note: Clear desks and clear screens are outside a code tool's reach entirely.
+  - id: A7.8
+    reason: organizational
+    note: Siting and protecting equipment is outside a code tool's reach entirely.
+  - id: A7.9
+    reason: organizational
+    note: Assets kept off the premises are outside a code tool's reach entirely.
+  - id: A7.10
+    reason: organizational
+    note: Storage media handling is outside a code tool's reach entirely.
+  - id: A7.11
+    reason: organizational
+    note: Supporting utilities such as power are outside a code tool's reach entirely.
+  - id: A7.12
+    reason: organizational
+    note: Cabling security is outside a code tool's reach entirely.
+  - id: A7.13
+    reason: organizational
+    note: Equipment maintenance is outside a code tool's reach entirely.
+  - id: A7.14
+    reason: organizational
+    note: Disposal and re-use of equipment is outside a code tool's reach entirely.
+
+  # 8 — Technological controls not covered above.
+  - id: A8.1
+    reason: organizational
+    note: >-
+      User endpoint devices are managed by the organisation's device management, not
+      by anything in a code change.
+  - id: A8.2
+    reason: organizational
+    note: >-
+      Allocating and restricting privileged access is the organisation's
+      access-management process. Code that grants a privilege is not the control.
+  - id: A8.3
+    reason: not-yet-built
+    note: >-
+      Restricting access to information has a real code angle: whether every read or
+      write of a protected record passes an authorization check on the same path.
+      The secure-defaults layer states the rule, but this pack carries no fail
+      condition for it yet.
+  - id: A8.5
+    reason: not-yet-built
+    note: >-
+      Secure authentication has a real code angle — password hashing, rate limits on
+      authentication endpoints, token lifetimes — and the secure-defaults layer
+      states the rules. This pack does not yet carry a fail condition for them.
+  - id: A8.6
+    reason: organizational
+    note: Capacity management is an operations activity over running systems.
+  - id: A8.7
+    reason: organizational
+    note: >-
+      Protection against malware is detection software on endpoints and servers plus
+      user awareness. Nothing in a diff establishes it.
+  - id: A8.10
+    reason: not-yet-built
+    note: >-
+      Deleting information when it is no longer needed has a code angle: a change
+      that stores a new kind of personal data could be checked for a deletion path.
+      This pack does not check it yet.
+  - id: A8.11
+    reason: not-yet-built
+    note: >-
+      Data masking has a code angle in what an application outputs. Personal data
+      written to a log is already checked under A8.15; masking in other outputs is not
+      checked yet.
+  - id: A8.12
+    reason: organizational
+    note: Data leakage prevention runs as monitoring over systems, networks and endpoints.
+  - id: A8.13
+    reason: organizational
+    note: Backups are taken and tested by operations, not by a code change.
+  - id: A8.14
+    reason: organizational
+    note: Redundancy of processing facilities is an infrastructure property.
+  - id: A8.16
+    reason: organizational
+    note: >-
+      Monitoring networks and systems for anomalous behaviour is an operations
+      activity. The logging a change adds is checked under A8.15.
+  - id: A8.17
+    reason: organizational
+    note: Clock synchronisation is an infrastructure property.
+  - id: A8.18
+    reason: organizational
+    note: Restricting privileged utility programs is an operations control over running systems.
+  - id: A8.19
+    reason: organizational
+    note: Controlling software installed on operational systems is an operations process.
+  - id: A8.20
+    reason: organizational
+    note: >-
+      Network security is an infrastructure control. Where network rules are defined
+      as code, a change to them is checked as configuration under A8.9.
+  - id: A8.21
+    reason: organizational
+    note: >-
+      Security of network services is agreed with and monitored at the provider.
+      Where a service's settings are defined as code, a change to them is checked as
+      configuration under A8.9.
+  - id: A8.22
+    reason: organizational
+    note: >-
+      Segregating networks is an infrastructure control. Where segments are defined
+      as code, a change to them is checked as configuration under A8.9.
+  - id: A8.23
+    reason: organizational
+    note: Web filtering is an infrastructure control over users' access to external sites.
+  - id: A8.27
+    reason: not-yet-built
+    note: >-
+      Secure architecture and engineering principles have a lifecycle angle: design.md
+      is where they would be applied. But design.md records one design, not the
+      organisation's established and maintained principles, so this pack does not
+      claim the control.
+  - id: A8.30
+    reason: organizational
+    note: >-
+      Directing and monitoring outsourced development is supplier management. An
+      outsourced team working inside this lifecycle leaves the same trail as anyone
+      else, but that does not evidence the oversight.
+  - id: A8.33
+    reason: not-yet-built
+    note: >-
+      Protecting test information has a code angle: fixtures copied from production
+      data could be flagged. This pack does not check it yet.
+  - id: A8.34
+    reason: organizational
+    note: Protecting systems during audit testing is planned between auditor and management.

package/packs/iso27001/guidance/iso27001-constraints.md

@@ -0,0 +1,99 @@
+---
+name: iso27001-constraints
+description: ISO/IEC 27001:2022 Annex A constraints that apply while code is being written
+---
+# ISO 27001 Constraints
+
+**This pack's control text has not been reviewed by a compliance practitioner.**
+It was written by an engineer reading the standard. Treat it as a working draft: useful
+for applying controls while you write code, not as an opinion on whether your controls
+are adequate. Nothing here makes a project ISO 27001 certified, attested, or
+audit-ready.
+
+The control text paraphrases the standard in this pack's own words and cites control
+numbers only. It quotes nothing: ISO's text is copyrighted, and the standard itself is
+obtained from ISO.
+
+## Edition and numbering
+
+This pack targets **ISO/IEC 27001:2022** only. The 2013 edition's certificates expired on
+2025-10-31, and its numbering — A.14 and the rest — does not apply here.
+
+Control ids are written `A<theme>.<n>`: `A8.25` means Annex A control 8.25. Annex A has
+93 controls in four themes — 5 organizational, 6 people, 7 physical, 8 technological.
+
+## What this pack does not cover
+
+It covers **Annex A controls only**. Clauses 4–10 of the standard — the information
+security management system: its scope, the risk assessment, the Statement of
+Applicability, internal audit and management review — are not covered, and a code tool
+cannot speak to them. Certification is of the management system, not of a codebase or
+its development process, so no output of this pack bears on whether an organisation
+would be certified.
+
+Of the 93 Annex A controls, 12 are covered. The other 81 are listed in the pack's
+`controls.yaml` under `excluded:` with a reason: `organizational` where nothing a code
+tool reads can speak to the control, `not-yet-built` where a code lifecycle could say
+something and this pack does not yet.
+
+## Which controls apply, and when
+
+| Phase | Controls to have in mind |
+|---|---|
+| Requirements | A5.8, A8.25, A8.26, A8.32 |
+| Design | A5.8, A8.25, A8.26, A8.28, A8.32 |
+| Implementation | A8.4, A8.8, A8.9, A8.15, A8.24, A8.25, A8.28, A8.31, A8.32 |
+| Testing | A8.25, A8.29, A8.32 |
+| Deployment | A8.4, A8.8, A8.9, A8.15, A8.24, A8.25, A8.31, A8.32 |
+| Maintenance | A8.8, A8.15 |
+
+Run `aidlc compliance check` for each control's exact fail condition. Apply the fail
+condition as written rather than your reading of the control — that is what makes two
+reviews of the same change agree.
+
+## Five controls are evidenced. Seven are only checked.
+
+**A5.8, A8.25, A8.26, A8.29 and A8.32 are evidenced.** They are controls over how
+software is developed and changed, and this lifecycle *is* a development and change
+process, so the artifact trail demonstrates them.
+
+**A8.4, A8.8, A8.9, A8.15, A8.24, A8.28 and A8.31 are checked only.** They operate over a
+running system or its surroundings. No document establishes that your logs are analysed
+or that your environments stay separate — so the pack gives you a fail condition to
+apply, and the trail records that you applied it. A report will say which is which.
+Never present a checked-only control as evidence.
+
+## What the evidenced controls ask of you while you build
+
+Make sure each of these leaves a record, because the record is the evidence:
+
+- **A5.8, security in project work.** `design.md` names the change's security
+  considerations — each risk and how it is handled — or says plainly that there are none.
+- **A8.25, a secure development life cycle.** The change passes through every phase its
+  template requires, and `transitions.log` shows it.
+- **A8.26, application security requirements.** When the change handles sensitive data,
+  authentication or access control, `requirements.md` carries an acceptance criterion
+  stating the security requirement.
+- **A8.29, security testing.** `test-results.md` names an outcome, and every security
+  criterion has a referencing test.
+- **A8.32, change management.** Numbered criteria authorise the change, `design.md` names
+  what it touches, `test-results.md` records the test, and `deployment-record.md` records
+  what shipped and how to roll it back.
+
+## What A8.32 does not evidence here
+
+The trail shows a change passed through requirements, design, testing and deployment, and
+a requirement changed after its phase closed is recorded when it goes through
+`aidlc amend`, which walks the impact and reopens the phases it invalidates. An artifact
+edited directly after its phase closed — without `aidlc amend` — is **not** detected:
+every gate still passes. So the trail does **not** establish that `requirements.md` and
+the shipped code still agree. Do not represent this pack's A8.32 output as evidence of
+that agreement.
+
+## Security rules live in one place, not here
+
+This pack does not restate the project's security rules. Read
+`.aidlc/guidance/secure-defaults.md` and apply it. The seven checked-only controls
+reference its sections — least privilege, dependency security, transport and data
+protection, error handling and logging, input validation, secrets management — so there
+is exactly one place to change when a rule changes.

package/packs/iso27001/pack.yaml

@@ -0,0 +1,29 @@
+id: iso27001
+# The edition is part of the name on purpose. The report prints this string as its
+# section heading, and the control numbers only mean something against the 2022
+# edition: the 2013 edition's certificates expired on 2025-10-31 and its A.14-style
+# numbering is gone. A ragged column in `aidlc compliance list` is the accepted cost
+# (iso-27001-pack/AC-2).
+regime: ISO 27001:2022
+version: 0.1.0
+
+# ISO/IEC 27001 is a management-system standard any organisation can certify
+# against, so like SOC 2 it is not industry-scoped.
+industries:
+  - any
+
+entitlement: unrestricted
+
+# Null on purpose. The control text in this pack was written by an engineer reading
+# the standard, not by a compliance practitioner. Nulling this field obliges the
+# constraint layer to say so, obliges every report to say so, and makes a doctor
+# check watch for someone editing the statement out.
+reviewed_by: null
+
+layers:
+  - name: iso27001-constraints
+    file: iso27001-constraints.md
+    # Pack layers are delivered as a read-instruction whatever their size. A small
+    # layer that got inlined would put pack text inside an emitted skill, which is
+    # forbidden outright.
+    always_pointer: true

package/packs/soc2/controls.yaml

@@ -102,9 +102,14 @@ controls:
       transmission, movement or removal.
     look_at: Network client configuration and request targets in the change.
     fails_when: >-
-      An added line targets a plain-HTTP URL, so protected information could be
-      transmitted without transport encryption.
-    pattern: "http://(?!localhost|127\\.0\\.0\\.1|\\[::1\\])"
+      An added line targets a plain-HTTP URL whose host is not exactly localhost,
+      127.0.0.1 or [::1], so protected information could be transmitted without
+      transport encryption.
+    # Case is spelled out letter by letter because the check compiles patterns with no
+    # flags. The trailing lookahead is the host boundary: localhost-api.corp.net and
+    # localhost@evil.example.com are not loopback (plain-http-check-misses-loopback-lookalikes).
+    # ISO 27001 A8.24 ships the same string, and plain-http-pattern.test.ts keeps them equal.
+    pattern: "[hH][tT][tT][pP]://(?!(?:[lL][oO][cC][aA][lL][hH][oO][sS][tT]|127\\.0\\.0\\.1|\\[::1\\])(?::\\d+)?(?![\\w:@%~-]|\\.[\\w-]))"
     references: secure-defaults#transport-and-data-protection
 
   - id: CC6.8

package/resources/rules/unattended.md

@@ -15,6 +15,10 @@ A situation no entry below covers is a hard stop. Guessing is what this mode exi
 
 Append one entry per default or hard stop to `.aidlc/state/<instance>/unattended-stops.md`: a `## <n>. <title> — <slug>` heading, then **Source:** (skill and section, or rule), **Instruction:** (the exact text), **Decided:** (the default, or "hard stop"), **Why:** (why it is safe, or which hard-stop class). A Question Protocol answer also carries `(unattended default)` in its `[Answer]:` — how a reviewer finds every choice nobody made.
 
+## Waiting for a command
+
+Unattended, the end of the turn is the end of the session, and a command still running dies with it. Run a long command in the foreground, or poll it inside the turn until it ends. Never end the turn while it runs, or to wait for a wakeup or a notification.
+
 ## Hard stop
 
 Always a hard stop:

package/skills/00-overview.md

@@ -3,6 +3,8 @@ name: aidlc-overview
 description: Framework overview and state protocol for the AI Development Lifecycle
 phase: ideation
 priority: 100
+invocation: routed
+activation: none
 ---
 # AIDLC Framework Overview
 

package/skills/01-getting-started.md

@@ -3,6 +3,8 @@ name: aidlc-getting-started
 description: Helps users get started with AIDLC — responds to onboarding questions, suggests templates, and guides first steps
 phase: ideation
 priority: 95
+invocation: routed
+activation: none
 trigger: When the user asks how to get started, how to use the framework, or asks about fixing bugs, adding features, or beginning work
 ---
 # Getting Started with AIDLC

package/skills/02-first-activation.md

@@ -3,6 +3,8 @@ name: aidlc-first-activation
 description: Auto-discovers a brownfield project on first activation — scans codebase, asks about extra context folders, writes context docs
 phase: ideation
 priority: 98
+invocation: routed
+activation: none
 trigger: When AIDLC is installed but `.aidlc/context/` does not exist or contains no files
 ---
 # First Activation — Project Discovery

package/skills/03-entry-point.md

@@ -3,6 +3,7 @@ name: aidlc
 description: Entry point for AIDLC — reads lifecycle state and offers the next actions (continue an instance, start new work, check status, review an artifact)
 phase: ideation
 priority: 99
+invocation: auto
 trigger: When the user invokes the aidlc skill directly or asks what lifecycle actions are available
 native_mode_hint:
   claude-code: >-

package/skills/04-roadmap.md

@@ -3,6 +3,8 @@ name: aidlc-roadmap
 description: Captures roadmap items into .aidlc/roadmap/inbox/ at any moment — no instance, claim, or phase required — and browses, triages, promotes, or drops them
 phase: ideation
 priority: 90
+arguments: "[idea text]"
+invocation: routed
 trigger: When the user says "idea:", asks to capture/record an idea or roadmap item, wants to browse the roadmap, or wants to triage, promote, or drop an item, or asks to start a roadmap item in a new worktree
 native_mode_hint:
   claude-code: >-

package/skills/05-constitution.md

@@ -3,6 +3,8 @@ name: aidlc-constitution
 description: Turns a product vision document into the repo's constitution — what this repo is for and what it must never become — and keeps it in step when the vision is updated
 phase: ideation
 priority: 88
+arguments: "[path to the vision document]"
+invocation: routed
 trigger: When the user points at a product vision document, asks what this repo is or is not allowed to do, asks to create or update a project constitution, or when the vision document has changed
 native_mode_hint:
   claude-code: >-

package/skills/10-ideation.md

@@ -3,6 +3,8 @@ name: aidlc-ideation
 description: Guides the Ideation phase — exploring the problem space, defining goals and constraints
 phase: ideation
 priority: 50
+invocation: routed
+tier: reasoning
 ---
 # Ideation Phase
 

package/skills/20-requirements.md

@@ -3,6 +3,8 @@ name: aidlc-requirements
 description: Guides the Requirements phase — defining acceptance criteria and user stories
 phase: requirements
 priority: 50
+invocation: routed
+tier: reasoning
 ---
 # Requirements Phase
 

package/skills/30-design.md

@@ -3,6 +3,8 @@ name: aidlc-design
 description: Guides the Design phase — architecture decisions, interfaces, and data flow
 phase: design
 priority: 50
+invocation: routed
+tier: reasoning
 ---
 # Design Phase
 

package/skills/40-implementation.md

@@ -3,6 +3,8 @@ name: aidlc-implementation
 description: Guides the Implementation phase — writing code following the design and project conventions
 phase: implementation
 priority: 50
+invocation: routed
+tier: standard
 ---
 # Implementation Phase
 

package/skills/50-testing.md

@@ -3,6 +3,8 @@ name: aidlc-testing
 description: Guides the Testing phase — verifying implementation against requirements
 phase: testing
 priority: 50
+invocation: routed
+tier: mechanical
 ---
 # Testing Phase
 

package/skills/60-deployment.md

@@ -3,6 +3,8 @@ name: aidlc-deployment
 description: Guides the Deployment phase — release preparation, validation, and execution
 phase: deployment
 priority: 50
+invocation: routed
+tier: mechanical
 ---
 # Deployment Phase
 

package/skills/70-maintenance.md

@@ -3,6 +3,8 @@ name: aidlc-maintenance
 description: Guides the Maintenance phase — monitoring, iteration, and documentation upkeep
 phase: maintenance
 priority: 50
+invocation: routed
+tier: standard
 ---
 # Maintenance Phase
 

package/skills/80-review.md

@@ -4,6 +4,9 @@ description: Performs adversarial review of lifecycle artifacts — examining fo
 phase: requirements
 trigger: Activated when a review is requested for any artifact or phase
 priority: 60
+arguments: "<instance> <artifact>"
+invocation: routed
+activation: none
 agent: aidlc-reviewer
 ---
 # Adversarial Review

package/skills/81-continue.md

@@ -3,6 +3,8 @@ name: aidlc-continue
 description: Resumes a lifecycle instance from the next incomplete step with minimal context loading
 phase: implementation
 priority: 70
+arguments: "[instance]"
+invocation: auto
 ---
 # Lifecycle Continuation
 

package/skills/82-add-action.md

@@ -3,6 +3,8 @@ name: aidlc-add-action
 description: Translates natural language automation descriptions into lifecycle action declarations
 phase: implementation
 priority: 55
+arguments: "<what should happen, and when>"
+invocation: routed
 ---
 # AI-Assisted Action Authoring
 

package/skills/83-add-skill.md

@@ -3,6 +3,8 @@ name: aidlc-add-skill
 description: Turns a described repeatable operation into an app-owned operational skill with built-in verification
 phase: implementation
 priority: 54
+arguments: "<the operation to automate>"
+invocation: routed
 ---
 # Operational Skill Authoring
 

package/skills/84-autopilot.md

@@ -3,6 +3,9 @@ name: aidlc-autopilot
 description: Works the next backlog items in the background — "do the next 3 items" or "do all the items" — pauses and resumes that run, and reports how to watch and stop
 phase: implementation
 priority: 60
+arguments: "[<n> | all | pause | resume]"
+invocation: user
+activation: none
 trigger: When the user asks to do, work, build or ship the next n backlog items, or all of them, without supervising each one — or to pause or resume that run
 ---
 # Autopilot

package/skills/85-autopilot-stop.md

@@ -3,6 +3,8 @@ name: aidlc-autopilot-stop
 description: Stops the background autopilot run — nothing further is started, merged or released
 phase: implementation
 priority: 60
+invocation: user
+activation: none
 trigger: When the user asks to stop or halt autopilot or the background backlog run
 ---
 # Stop Autopilot

package/skills/90-retrospective.md

@@ -3,6 +3,8 @@ name: aidlc-retrospective
 description: Runs the completion retrospective — captures lessons into the guidance layer, and consolidates the lessons file on demand
 phase: maintenance
 priority: 55
+arguments: "[instance]"
+invocation: routed
 trigger: When an instance reaches its completion moment, a retro-pending marker exists, or the user asks for a retrospective or lessons consolidation
 ---
 # Retrospective