@rasensio/aidlc-content 1.41.0 → 1.43.0

package/package.json

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

package/resources/rules/question-protocol.md

@@ -38,4 +38,6 @@ Each question in the file ends with an `[Answer]:` tag — blank while open, car
 
 With no interactive terminal, write the file, say where it is, and end the turn. Never assume an answer.
 
+**Unattended (`AIDLC_UNATTENDED=1`)** is the one exception, and it is not an assumption: take the recommended option, write it into `[Answer]:` followed by `(unattended default)`, and log it — or, when the recommended option falls in a hard-stop class, stop. Both per `.aidlc/resources/rules/unattended.md`.
+
 **At most five questions stand open at once.** At the limit, answering — or accepting the stated defaults — comes before asking another. The cap counts open questions, not questions asked: a long negotiation is fine, an accumulating pile is not.

package/resources/rules/unattended.md

@@ -0,0 +1,60 @@
+# The unattended rule
+
+This file is the only statement of the rule. Skills point here instead of restating it, so there is no second copy to drift.
+
+Unattended mode is on exactly when the environment variable `AIDLC_UNATTENDED` is `1` (`printenv AIDLC_UNATTENDED`). Otherwise every skill behaves as written. Nobody answers in this mode, so every place a skill would stop for a person has one outcome:
+
+- **Default and log** — take the named default, log it, carry on.
+- **Hard stop** — log it, park the item, release the claim, end the session.
+- **Release boundary** — the normal end of an unattended run. Not a hard stop, and the item is not parked.
+
+A situation no entry below covers is a hard stop. Guessing is what this mode exists to prevent.
+
+## The log
+
+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.
+
+## Hard stop
+
+Always a hard stop:
+
+1. Crossing a prohibition in `.aidlc/context/constitution.md`.
+2. Deleting or overwriting data this session did not create.
+3. Changing authentication, secrets, permissions or CI tokens, or handling real credentials.
+4. Growing scope beyond the roadmap item's "What success looks like".
+
+To stop:
+
+1. Append the log entry.
+2. Run `aidlc roadmap park <instance> --reason "<slug>: <one line>"`.
+3. Run `aidlc release <instance>`.
+4. End the session. Commit nothing more; try no other route to the same outcome.
+
+## The release boundary
+
+When testing completes, write the deployment record's release plan and end the session. Do not push, open a pull request, merge or release: whatever runs the agent owns those, and two actors on one release lane is how two releases collided on 2026-10-01.
+
+## Every known stop
+
+Each bullet begins with its one outcome; a condition after it is part of the rule.
+
+- `entry-menu` — **default and log**: route to what the prompt names.
+- `instance-name-taken` — **hard stop**: another session's work or an abandoned start, indistinguishable from here.
+- `template-choice` — **default and log**: what the item or prompt names, else `defaults:` in `.aidlc/config.yaml`.
+- `worktree-hand-off` — **default and log**: when the prompt says to continue, continue in the worktree.
+- `roadmap-move-uncommitted` — **default and log**: leave it uncommitted; the caller commits.
+- `roadmap-item-unlinked` — **default and log**: use `aidlc start --roadmap-item`; never move the item by hand.
+- `requirements-input` — **default and log**: read `roadmap-item.md`; with neither it nor an ideation artifact, hard stop.
+- `open-question` — **default and log**: the recommended option, marked `(unattended default)`; if it is a hard-stop class, hard stop — never another option.
+- `requirements-confirmation` — **default and log**: hard stop if the requirements exceed the roadmap item.
+- `design-confirmation` — **default and log**: the same scope test.
+- `phase-end-turn` — **default and log**: continue into the next phase.
+- `fresh-session` — **default and log**: continue; the runner decides where sessions start.
+- `own-change-revert` — **default and log**: reverting this session's own change, after keeping a copy.
+- `generated-output-discard` — **hard stop**: discarding output this session did not write.
+- `sensitive-operation` — **hard stop**: deletions, infrastructure, permissions, credentials — except `own-change-revert`.
+- `shared-state-prune` — **default and log**: it removes only entries whose worktree is gone and branch merged or deleted, and names each; log the names.
+- `commit-incrementally` — **default and log**: on the instance branch only; never `main`, never push.
+- `testing-security` — **hard stop**: production-like environments, real credentials, destructive operations.
+- `platform-unknown` — **default and log**: carry on; the runner sets `AIDLC_AGENT`.
+- `release-boundary` — **release boundary**: completing testing.

package/skills/00-overview.md

@@ -90,7 +90,7 @@ On each lifecycle event — `on-instance-start`, `on-phase-enter`, `on-phase-exi
 
 ## Question Protocol
 
-When to ask the user something, how the question is written, and where it is recorded. The rule is in `.aidlc/resources/rules/question-protocol.md`.
+When to ask the user something, how the question is written, and where it is recorded. The rule is in `.aidlc/resources/rules/question-protocol.md`. With nobody there: `.aidlc/resources/rules/unattended.md`.
 
 ## Ending a Phase or a Review
 

package/skills/03-entry-point.md

@@ -8,11 +8,13 @@ native_mode_hint:
   claude-code: >-
     This skill is an interactive entry point, not a phase artifact. Do not
     enter plan mode. Read lifecycle state, present the menu, and wait for
-    the user's choice before doing any work.
+    the user's choice before doing any work — unless their message already
+    says what they want; then route to it directly.
   copilot: >-
     This skill is an interactive entry point, not a phase artifact. Stay in the
     default agent — do not switch to plan mode. Read lifecycle state, present the
-    menu, and wait for the user's choice before doing any work.
+    menu, and wait for the user's choice before doing any work — unless their
+    message already says what they want; then route to it directly.
 ---
 # AIDLC Entry Point
 

package/skills/04-roadmap.md

@@ -143,6 +143,8 @@ List each status directory, reading **only frontmatter and the containing direct
 
 For a `hold/` item, show whether it is **parked or declined**, with its reason, from the last `history` entry — that entry is in the frontmatter, so this costs nothing extra. An item with no reason recorded is reported as `hold — reason not recorded`, never guessed at: parked and declined are opposite answers, and a wrong one either revives work somebody killed or buries work somebody agreed to.
 
+**`aidlc roadmap next`** is the deterministic answer to "what next?": the `backlog/` item with the lowest `priority` among those whose `depends_on` are all `done`, unranked items last, ties by file name (`--explain` shows the order and what was skipped and why; `--json` for scripts). It is read-only and never promotes — promoting stays a person's decision. `priority` is an ordinary extension field a project declares in `roadmap.item_fields`; a rank, where 1 is first.
+
 The frontmatter-only rule holds for browsing, which is a list and must stay cheap enough to run over the whole roadmap. **Triage** below is the one flow allowed into the body, and only as far as the executive summary.
 
 A filename appearing in two status directories is an error: report it rather than guessing which one is current.
@@ -176,9 +178,8 @@ When the user asks for a worktree ("create a new worktree for roadmap `<file>`")
 
 1. **Find the item** by file name, `id`, or title, in `backlog/` or `inbox/`. Asking for a worktree counts as choosing to skip triage. When more than one item matches, list them and ask which one.
 2. **Instance name**: the item's file name without its date prefix and extension (the item filed as `20260929-say-what-to-do-next` becomes `say-what-to-do-next`). Template and scope come from the config defaults, unless the item or the user names them.
-3. **Create the instance with** `aidlc start <template> --name <name> --scope <scope> --worktree --non-interactive`. Take the worktree path from the `Worktree:` line it prints. That command creates the branch and the worktree and fires `on-instance-start`; do not repeat any of it by hand.
-4. **Seed the instance inside the worktree** (`<worktree>/.aidlc/state/<name>/`), not the primary checkout. Copy the item into it per step 5 above. Keep the roadmap move (step 6) in the primary checkout, as always.
-5. **Hand off. Do not start the phase in this session.** The work belongs to the new session. End with the exact command that opens it:
+3. **Create the instance with** `aidlc start <template> --name <name> --scope <scope> --worktree --non-interactive --roadmap-item <item-file>`. Take the worktree path from the `Worktree:` line it prints. That one command creates the branch and the worktree, fires `on-instance-start`, sets the item's `promoted_to`, moves it to `in-progress/` in the primary checkout, and copies it into the instance as `roadmap-item.md` — which is the seeding step 5 above asks for. Do none of it by hand: a hand-made move is the step that got skipped. The move is left uncommitted in the primary checkout; committing it is yours.
+4. **Hand off. Do not start the phase in this session** — unless the user's own message asks you to continue here, in which case `cd` into the worktree and follow **aidlc-continue** there. Otherwise the work belongs to the new session. End with the exact command that opens it:
    ```
    cd <worktree> && claude "/aidlc-continue <name>"
    ```

package/skills/20-requirements.md

@@ -39,7 +39,7 @@ See **The context rule** (`.aidlc/resources/rules/context.md`).
 
 > {{glossary:artifact}}
 
-1. **Gather requirements.** If a Full scope, read the ideation phase's artifact for context (`idea.md` for the feature templates, `research-question.md` for `spike`; `phase-ideation.yaml` names it). Otherwise, ask the user to describe desired behavior. Read the always-read guidance layers from `.aidlc/guidance/index.yaml` — see **The always-read rule** (`.aidlc/resources/rules/always-read.md`) for which layers those are and when to reach for the full `lessons.md`. Read `.aidlc/context/constitution.md` when it exists and apply the constitution rule in `.aidlc/resources/rules/constitution.md`.
+1. **Gather requirements.** If a Full scope, read the ideation phase's artifact for context (`idea.md` for the feature templates, `research-question.md` for `spike`; `phase-ideation.yaml` names it). At Standard scope, read the roadmap item the instance was promoted from (`roadmap-item.md` in its state directory). Ask the user to describe the desired behaviour only when there is neither. Unattended (`AIDLC_UNATTENDED=1`): no artifact and no item is a hard stop, per `.aidlc/resources/rules/unattended.md`. Read the always-read guidance layers from `.aidlc/guidance/index.yaml` — see **The always-read rule** (`.aidlc/resources/rules/always-read.md`) for which layers those are and when to reach for the full `lessons.md`. Read `.aidlc/context/constitution.md` when it exists and apply the constitution rule in `.aidlc/resources/rules/constitution.md`.
 2. **Write user stories.** Use the format: "As a [role], I want [capability], so that [benefit]."
 3. **Define acceptance criteria.** Each criterion must be:
    - Specific and unambiguous
@@ -78,7 +78,7 @@ When the instance uses the `bugfix` template, this phase produces `reproduction.
 
 - `requirements.md` exists with at least one user story and corresponding acceptance criteria
 - Each acceptance criterion is testable (has an observable pass/fail condition)
-- The user has confirmed the requirements are complete for the chosen scope
+- The user has confirmed the requirements are complete for the chosen scope. Unattended (`AIDLC_UNATTENDED=1`): log the confirmation as a default, or hard-stop when the requirements reach beyond the roadmap item, per `.aidlc/resources/rules/unattended.md`.
 
 ## Guidance
 

package/skills/30-design.md

@@ -66,7 +66,7 @@ transcript. See **The context rule** (`.aidlc/resources/rules/context.md`).
 - Every knowledge-graph symbol the design builds on was checked against the source
 - The design addresses all acceptance criteria from `requirements.md`
 - For templates requiring it: `tasks.md` exists and every active acceptance criterion is claimed by at least one task, or the gap is deliberate
-- The user has confirmed the design direction
+- The user has confirmed the design direction. Unattended (`AIDLC_UNATTENDED=1`): log the confirmation as a default, or hard-stop when the design reaches beyond the roadmap item, per `.aidlc/resources/rules/unattended.md`.
 
 ## Guidance
 

package/skills/40-implementation.md

@@ -44,7 +44,7 @@ Then the source files that task touches. See **The context rule** (`.aidlc/resou
 2. **Load guidance.** Read the always-read guidance layers from `.aidlc/guidance/index.yaml` — see **The always-read rule** (`.aidlc/resources/rules/always-read.md`) for which layers those are and when to reach for the full `lessons.md`. Apply their rules during implementation.
 3. **Execute the task breakdown.** When the instance has a `tasks.md` (produced in Design for full/quick-feature scope), read it and execute tasks in order: complete a task, then mark its checkbox `[x]` as part of the same work unit — never batch checkbox updates for later. A task that should not be done is deferred in place (`- [>] T<n>: <title> (deferred YYYY-MM-DD: <reason>)`) with a dated reason, never skipped silently or deleted; the implementation→testing gate blocks on open tasks. For bugfix scope, create the optional `tasks.md` at implementation start when the fix spans more than one commit-sized unit. For Micro scope, reference the task description and acceptance criteria directly — no task file.
 4. **Write code.** Follow the design interfaces. Match existing code style (naming, formatting, error handling patterns).
-5. **Handle sensitive operations.** Before executing any of the following, describe the action and wait for explicit user confirmation:
+5. **Handle sensitive operations.** Before executing any of the following, describe the action and wait for explicit user confirmation (unattended, `AIDLC_UNATTENDED=1`: each is a hard stop except reverting this session's own changes, per `.aidlc/resources/rules/unattended.md`):
    - File deletions or destructive operations
    - Infrastructure changes (provisioning, configuration)
    - Permission or access control modifications
@@ -70,6 +70,8 @@ Then the source files that task touches. See **The context rule** (`.aidlc/resou
 
 ## Security Confirmation
 
+Unattended (`AIDLC_UNATTENDED=1`): nobody can confirm, so everything this section asks to confirm is a hard stop, per `.aidlc/resources/rules/unattended.md`.
+
 Before proceeding with any sensitive operation during implementation:
 1. Describe what the operation does and what it affects
 2. State whether it is reversible

package/skills/50-testing.md

@@ -91,6 +91,8 @@ testing phase and record newly introduced advisories as findings.
 
 ## Security Confirmation
 
+Unattended (`AIDLC_UNATTENDED=1`): nobody can confirm, so everything this section asks to confirm is a hard stop, per `.aidlc/resources/rules/unattended.md`.
+
 If testing requires:
 - Access to production-like environments
 - Use of real credentials or sensitive data
@@ -102,6 +104,8 @@ You MUST describe the action, confirm it targets a safe environment, and wait fo
 
 When exit criteria are met, update `phase-testing.yaml` status to `complete` and append a transition record to `transitions.log`.
 
+Unattended (`AIDLC_UNATTENDED=1`): this is the release boundary. Write the deployment record's release plan and end the session — no push, pull request, merge or release — per `.aidlc/resources/rules/unattended.md`.
+
 Then end the turn as **The next-steps rule** (`.aidlc/resources/rules/next-steps.md`) says.
 
 **Changing a completed phase's artifact.** Do it only through an amendment — append an

package/skills/60-deployment.md

@@ -82,6 +82,8 @@ deployment checklist.
 
 ## Security Confirmation
 
+Unattended (`AIDLC_UNATTENDED=1`): nobody can confirm, so everything this section asks to confirm is a hard stop, per `.aidlc/resources/rules/unattended.md`.
+
 Deployment is inherently sensitive. You MUST:
 1. Confirm the target environment with the user (production vs. staging vs. dev)
 2. Present the full list of changes being deployed