@rse/ase 1.0.7 → 2.0.1

package/plugin/skills/ase-task-integrate/help.md

@@ -0,0 +1,187 @@
+
+##  NAME
+
+`ase-task-integrate` - Integrate a Task Change Set
+
+##  SYNOPSIS
+
+`ase-task-integrate`
+    [`--help`|`-h`]
+    [`--next`|`-n` *option*[,...]]
+    [`--worktree`|`-w` *name*]
+    [`--changeset`|`-c` *changeset*]
+    [`--draft`|`-d`]
+    [`--target`|`-t` *target*]
+    [`--mode`|`-m` `merge`|`rebase`|`squash`]
+    [`--no-cleanup`|`-K`]
+    [`--stateless`|`-S`]
+    [*id*]
+
+##  DESCRIPTION
+
+The `ase-task-integrate` skill delivers the *change set* of a task
+plan, as created by `ase-task-implement`, from the plan's *changeset*
+(the location of the change set) into the plan's *target* (the place
+of integration). The integration itself is performed by the skill
+`ase-repo-merge`, which commits still uncommitted changes of the
+change set, merges them into the target branch (through a regular
+merge, a rebase with fast-forward, or a squash merge, as selected via
+`--mode`), resolves merge conflicts semantically, and reports the
+verdict `MERGED`, `CONFLICT`, or `FAILED`.
+
+The *changeset* is selected by the plan's `Changeset:` frontmatter
+key (if absent, the configured default `project.task.default.changeset`),
+overridable via `--changeset`:
+
+-   `worktree` (default): the uncommitted changes and the checked-out
+    branch of the context worktree. If it equals the target branch
+    (only possible without `--worktree`), the integration just commits
+    the uncommitted changes in place.
+-   `branch:`*name*: the existing branch *name*.
+-   `attachment:`*name*: the attachment block of type `text/x-diff;
+    charset=utf-8; kind="<name>"` of the plan, which is applied on a
+    *temporary* branch at the commit it is based on, so drift of the
+    target is resolved by the merge. A *stale* attachment -- one whose
+    `Modified:` key is absent or older than the `Modified:` key of the
+    plan frontmatter -- stops the skill with an error, and so does an
+    already *delivered* one -- one whose `Desc:` key carries the
+    `merged` marker of an earlier `--no-cleanup` integration.
+-   `attachment:draft`: the *implementation draft* of the plan, as
+    created by `ase-task-implement --draft`, selectable via the
+    `--draft` shorthand.
+
+The skill does *not* maintain the *change set snapshot* of the plan
+(the attachment block of type `text/x-diff; charset=utf-8;
+kind="changeset"`), which only the `integrator` agent of `ase agent`
+updates after a successful integration, but passes an existing one
+through unchanged.
+
+The *target* is selected by the plan's `Target:` frontmatter key
+(if absent, the configured default `project.task.default.target`),
+overridable via `--target`:
+
+-   `worktree`: the checked-out branch of the *origin* working copy,
+    i.e. the one the skill was started in (also with `--worktree`).
+-   `branch:`*name*: the existing branch *name*, which has to be
+    checked out in some worktree and to have no uncommitted changes.
+-   `source` (default): whatever the plan's `Source:` key refers to.
+
+The skill stops with an error -- touching nothing -- if the change set
+and the target are the same branch (except for the `worktree` changeset
+of the origin working copy, which just commits in place, see above), or
+if the change set carries neither commits beyond the target nor
+uncommitted changes. Likewise, a merge which leaves the content of the
+target unchanged, as the change set already landed earlier (e.g. on a
+repeated integration), counts as *no* integration: its empty merge
+commit is dropped again and the skill stops with an error. So it never
+reports a success without having delivered anything.
+
+Unless `--stateless` is given, the plan's `Status:` key follows the
+task lifecycle model: for `solo` the plan has to be `OPEN` (otherwise
+the integration is refused) and it becomes `CLOSED` on a successful
+integration and stays `OPEN` otherwise, for `enterprise` it becomes
+`INTEGRATING` before and `INTEGRATED` (on success), `QUALIFIED` (on
+nothing delivered), or `DEFERRED` (otherwise) after the integration,
+and for `team`, which defines no integration states, it stays
+untouched.
+
+After a successful integration, the user is asked whether to preserve
+or delete the task plan, unless `--next` pre-selects this choice.
+
+##  OPTIONS
+
+-   `--next`|`-n` *option*[,...]:
+    Automatically answer the user dialog for the next step. Recognized
+    tokens at this skill: `none` (default, interactive answer
+    required), `DONE` (preserve task plan and stop), or `DELETE` (hand
+    off to `ase-task-delete`).
+
+-   `--worktree`|`-w` *name*:
+    Operate on the *context worktree* `.ase/worktree/<name>` instead
+    of the current working copy, as for `ase-task-implement`. The
+    worktree has to exist already: an integration never creates it, so
+    a mistyped *name* stops the skill with an error. The option is
+    permitted for a `worktree` changeset only, as a `branch:` or
+    `attachment:` changeset would leave the context worktree unused.
+
+-   `--changeset`|`-c` *changeset*:
+    Override the plan's `Changeset:` key (`worktree`, `branch:`*name*,
+    or `attachment:`*name*) for this run, without changing the plan.
+
+-   `--draft`|`-d`:
+    Shorthand for `--changeset attachment:draft`: deliver the
+    *implementation draft* of the plan. Mutually exclusive with
+    `--changeset`.
+
+-   `--target`|`-t` *target*:
+    Override the plan's `Target:` key (`worktree`, `branch:`*name*, or
+    `source`) for this run, without changing the plan.
+
+-   `--mode`|`-m` `merge`|`rebase`|`squash`:
+    The merge mode, passed through to `ase-repo-merge` (default:
+    `merge`): `merge` creates a merge commit, `rebase` rebases the
+    change set branch (rewriting its commits) onto the target branch
+    and fast-forwards the target branch, and `squash` combines all
+    changes of the change set into one new commit on the target branch.
+
+-   `--no-cleanup`|`-K`:
+    After a successful integration, keep the delivered change set
+    instead of removing it: the branch and its worktree, or the
+    attachment block, which is then marked as delivered by appending
+    `, merged <commit>` to its `Desc:` key, so it is never delivered
+    again. Without this option, a delivered branch is removed only if
+    Git considers it merged (always for `--mode squash`) and its
+    worktree has no uncommitted changes. A temporary branch of an
+    attachment is always removed.
+
+-   `--stateless`|`-S`:
+    Leave the plan's `Status:` key untouched.
+
+##  ARGUMENTS
+
+-   *id*:
+    The unique identifier of the task whose change set should be
+    integrated. If omitted, the *current* task id is used.
+
+##  SCENARIOS
+
+-   You want the implemented change set committed to the code base
+-   You want a change set branch merged into its target branch
+-   You want a change set attachment delivered into the code base
+-   You want a reviewed implementation draft applied to the code base
+-   You want the task closed once its change set has landed
+
+##  EXAMPLES
+
+Integrate (commit) the change set of the current task plan:
+
+```text
+❯ /ase-task-integrate
+```
+
+Apply the implementation draft of the task `hello` and remove the
+draft attachment afterwards:
+
+```text
+❯ /ase-task-integrate --draft hello
+```
+
+Merge the change set branch of the task `hello` into `main` and
+keep the branch afterwards:
+
+```text
+❯ /ase-task-integrate --changeset branch:feature-hello --target branch:main --no-cleanup hello
+```
+
+Squash the change set branch of the task `hello` into one commit on
+its target:
+
+```text
+❯ /ase-task-integrate --changeset branch:feature-hello --mode squash hello
+```
+
+##  SEE ALSO
+
+[`ase-task-implement`](../ase-task-implement/help.md), [`ase-repo-merge`](../ase-repo-merge/help.md),
+[`ase-task-status`](../ase-task-status/help.md), [`ase-task-delete`](../ase-task-delete/help.md).
+

package/plugin/skills/ase-task-list/SKILL.md

@@ -19,7 +19,7 @@ List Task Plans
 
 <expand name="getopt"
     arg1="ase-task-list"
-    arg2="--verbose|-v --include|-i=none --exclude|-e=COMPLETED,CANCELLED">
+    arg2="--verbose|-v --include|-i=none --exclude|-e=finished">
     $ARGUMENTS
 </expand>
 
@@ -31,21 +31,40 @@ Procedure
 ---------
 
 1.  Determine the *effective state set* <states/>, i.e., the lifecycle
-    states a task plan has to be in to be listed at all. For this, parse
-    <getopt-option-include/> and <getopt-option-exclude/> as
+    states a task plan has to be in to be listed at all. For this, first
+    determine the *all states* set <all-states/> and the *finished
+    states* set <finished-states/> of the task lifecycle model
+    <ase-project-task-lifecycle/> of the current project:
+
+    -   If <ase-project-task-lifecycle/> is `solo` (or absent):
+        <all-states/> is `OPEN`, `SHELVED`, `CLOSED`, and `CANCELLED`,
+        and <finished-states/> is `CLOSED` and `CANCELLED`.
+
+    -   If <ase-project-task-lifecycle/> is `team`:
+        <all-states/> is `PLANNING`, `SHELVED`, `IMPLEMENTING`,
+        `STALLED`, `IMPLEMENTED`, and `CANCELLED`, and
+        <finished-states/> is `IMPLEMENTED` and `CANCELLED`.
+
+    -   If <ase-project-task-lifecycle/> is `enterprise`:
+        <all-states/> is `DRAFTED`, `SHELVED`, `PLANNING`, `PLANNED`,
+        `STALLED`, `IMPLEMENTING`, `IMPLEMENTED`, `DECLINED`,
+        `QUALIFYING`, `QUALIFIED`, `DEFERRED`, `INTEGRATING`, `INTEGRATED`,
+        and `CANCELLED`, and <finished-states/> is `INTEGRATED` and
+        `CANCELLED`.
+
+    Then parse <getopt-option-include/> and <getopt-option-exclude/> as
     comma-separated token lists, silently dropping the `none` sentinel
-    and any empty token. If a token <token/> is *not* one of the eight
-    `Status:` values `DRAFTED`, `REJECTED`, `APPROVED`, `DEFERRED`,
-    `STARTED`, `BLOCKED`, `COMPLETED`, or `CANCELLED`, only output the
-    following <template/> and then *STOP* processing the entire current
-    skill:
+    and any empty token, and replacing the `finished` sentinel with
+    <finished-states/>. If a token <token/> is *not* one of the
+    `Status:` values in <all-states/>, only output the following
+    <template/> and then *STOP* processing the entire current skill:
 
     <template>
     ⧉ **ASE**: ✪ skill: **ase-task-list**, ▶ ERROR: invalid state: **<token/>**
     </template>
 
-    Otherwise set <states/> to *all* eight states if both lists are
-    empty, to the *include* list if only it is non-empty, to all eight
+    Otherwise set <states/> to <all-states/> if both lists are
+    empty, to the *include* list if only it is non-empty, to <all-states/>
     *minus* the *exclude* list if only it is non-empty, and to the
     *include* list *minus* the *exclude* list if both are non-empty. If
     the resulting <states/> is *empty*, only output the following
@@ -61,18 +80,30 @@ Procedure
     hence emit no output at all):
 
     <ase-tpl-hint level="minimal">
-    The `--exclude` default `COMPLETED,CANCELLED` still applies -- add `--exclude none` to reach states like `COMPLETED` via `--include`.
+    The `--exclude` default `finished` (the finished states of the task lifecycle model) still applies -- add `--exclude none` to reach finished states via `--include`.
     </ase-tpl-hint>
 
 2.  Call the `ase_task_list(verbose: <getopt-option-verbose/>)` tool from
     the `ase` MCP server. The result is a structured object with a
     `tasks` array where each entry has an `id` and a `status` field, and
     -- if <getopt-option-verbose/> is `true` -- additionally an `mtime`
-    field (formatted as `YYYY-MM-DD HH:MM`). *Drop* from the `tasks`
-    array every entry whose `status` is *not* contained in <states/>. Do
-    not output anything.
+    field (formatted as `YYYY-MM-DD HH:MM`) and an `effort` field (the
+    T-shirt size `XS`, `S`, `M`, `L`, or `XL` of the task, empty if not
+    estimated). *Drop* from the `tasks`
+    array every entry whose `status` is contained in <all-states/> but
+    *not* in <states/>. *Keep* every entry whose `status` is *not*
+    contained in <all-states/> at all, regardless of <states/>, and
+    remember it as an *unknown-status entry*. Do not output anything.
+
+3.  For each *unknown-status entry* of step 2, output the following
+    <template/>, where <id/> and <status/> correspond to the entry and
+    <all-states/> is rendered as a comma-separated list:
+
+    <template>
+    ⧉ **ASE**: ◉ task: **<id/>**, ▶ WARNING: unknown status **<status/>** (expected one of: <all-states/>)
+    </template>
 
-3.  If the `tasks` array is empty, output the following <template/>:
+    Then, if the `tasks` array is empty, output the following <template/>:
 
     <template>
     ⧉ **ASE**: ◉ tasks: *(none)*
@@ -81,16 +112,17 @@ Procedure
     Else, dispatch on <getopt-option-verbose/>:
 
     -   If <getopt-option-verbose/> is `true`, output the list of tasks
-        with the following <template/>, where each <id/>, <status/>, and
-        <mtime/> correspond to an entry in the task list:
+        with the following <template/>, where each <id/>, <status/>,
+        <effort/>, and <mtime/> correspond to an entry in the task list,
+        with an empty <effort/> rendered as `-`:
 
         <template>
         ⧉ **ASE**: ◉ tasks:
 
-        | *Task Id* | *Status*    | *Last Modified*    |
-        |-----------|-------------|--------------------|
-        | **<id/>** | `<status/>` | `<mtime/>`         |
-        | [...]     | [...]       | [...]              |
+        | *Task Id* | *Status*    | *Effort*    | *Last Modified*    |
+        |-----------|-------------|-------------|--------------------|
+        | **<id/>** | `<status/>` | `<effort/>` | `<mtime/>`         |
+        | [...]     | [...]       | [...]       | [...]              |
 
         </template>
 
@@ -130,11 +162,11 @@ Procedure
 
     <if condition="<getopt-option-verbose/> is not equal `true`">
     <ase-tpl-hint level="verbose">
-    Use `/ase-task-list --verbose` to additionally show the status and the last-modified timestamp of each task plan.
+    Use `/ase-task-list --verbose` to additionally show the status, the effort size, and the last-modified timestamp of each task plan.
     </ase-tpl-hint>
     </if>
 
     <ase-tpl-hint level="verbose">
-    Use `/ase-task-list --include`/`--exclude` to narrow the listing to certain lifecycle states, e.g. `--include STARTED,BLOCKED`.
+    Use `/ase-task-list --include`/`--exclude` to narrow the listing to certain lifecycle states, e.g. `--include IMPLEMENTING,STALLED`.
     </ase-tpl-hint>
 

package/plugin/skills/ase-task-list/help.md

@@ -16,42 +16,66 @@
 The `ase-task-list` skill lists all available *task ids* in the
 current project by calling the `ase_task_list` MCP tool. In the
 default mode, only the task ids are rendered as a single-column
-Markdown table. In verbose mode, the lifecycle status and the
-last-modified timestamp of each task plan are rendered as additional
-columns.
+Markdown table. In verbose mode, the lifecycle status, the effort size
+(see `ase-task-estimate`), and the last-modified timestamp of each task
+plan are rendered as additional columns.
 
 The listing is restricted to an *effective state set*, derived from the
-`Status:` frontmatter key of each task plan (which defaults to `DRAFTED`
-for a plan carrying no such key): with `--include` only, exactly the
-listed states are shown; with `--exclude` only, all states except the
-listed ones; with both, the included ones minus the excluded ones. An
-unknown state, or a combination which cancels out to an empty set,
-aborts the skill with an error. By default,
-`--exclude COMPLETED,CANCELLED` is in effect, so finished and
-abandoned task plans stay out of the way. The eight states are:
+`Status:` frontmatter key of each task plan (which defaults to the
+initial state of the task lifecycle model for a plan carrying no such
+key): with `--include` only, exactly the listed states are shown; with
+`--exclude` only, all states except the listed ones; with both, the
+included ones minus the excluded ones. An unknown state, or a
+combination which cancels out to an empty set, aborts the skill with an
+error. The `finished` sentinel stands for the finished states of the
+task lifecycle model. By default, `--exclude finished` is in effect, so
+finished and abandoned task plans stay out of the way. A task plan whose
+`Status:` is not a state of the task lifecycle model at all is never
+filtered out: it is kept in the listing and reported with a warning.
+
+The states depend on the task lifecycle model configured for the
+project via `project.task.lifecycle`. The `solo` model (default) has
+the 4 states (initial: `OPEN`, finished: `CLOSED` and `CANCELLED`):
 
 ```text
-DRAFTED   APPROVED  STARTED  COMPLETED
-REJECTED  DEFERRED  BLOCKED  CANCELLED
+OPEN  SHELVED  CLOSED  CANCELLED
+```
+
+The `team` model has the 6 states (initial: `PLANNING`, finished:
+`IMPLEMENTED` and `CANCELLED`):
+
+```text
+PLANNING  SHELVED  IMPLEMENTING  STALLED  IMPLEMENTED  CANCELLED
+```
+
+The `enterprise` model has the 14 states (initial: `DRAFTED`, finished:
+`INTEGRATED` and `CANCELLED`):
+
+```text
+DRAFTED      SHELVED   PLANNING     PLANNED   STALLED
+IMPLEMENTING IMPLEMENTED DECLINED   QUALIFYING QUALIFIED
+DEFERRED     INTEGRATING INTEGRATED CANCELLED
 ```
 
 ##  OPTIONS
 
 -   `--verbose`|`-v`:
-    Render an additional `Status` column with the lifecycle state and an
-    additional `Last Modified` column with the `YYYY-MM-DD HH:MM`
-    timestamp of each task plan.
+    Render an additional `Status` column with the lifecycle state, an
+    additional `Effort` column with the T-shirt size (`-` if not
+    estimated), and an additional `Last Modified` column with the
+    `YYYY-MM-DD HH:MM` timestamp of each task plan.
 
 -   `--include`|`-i`=*state*[`,`...]:
     Restrict the listed task plans to the given comma-separated list of
-    lifecycle states (e.g. `STARTED,BLOCKED`). Without this option, all
-    eight states are listed. The `none` sentinel selects no state at all.
+    lifecycle states (e.g. `IMPLEMENTING,STALLED`). Without this option,
+    all states are listed. The `none` sentinel selects no state at all,
+    the `finished` sentinel selects the finished states.
 
 -   `--exclude`|`-e`=*state*[`,`...]:
     Remove the given comma-separated list of lifecycle states from the
     listed task plans. Applied *after* `--include`, so
-    `-i DRAFTED,STARTED -e STARTED` lists `DRAFTED` only. Defaults to
-    `COMPLETED,CANCELLED`; pass `--exclude none` to suppress the
+    `-i PLANNING,IMPLEMENTING -e IMPLEMENTING` lists `PLANNING` only.
+    Defaults to `finished`; pass `--exclude none` to suppress the
     default and list task plans in every state.
 
 ##  SCENARIOS
@@ -83,7 +107,7 @@ List the task ids of every task plan, including the finished ones:
 List only the task ids of the task plans currently under work:
 
 ```text
-❯ /ase-task-list --include STARTED,BLOCKED
+❯ /ase-task-list --include IMPLEMENTING,STALLED
 ```
 
 ##  SEE ALSO

package/plugin/skills/ase-task-reboot/SKILL.md

@@ -21,16 +21,17 @@ Reboot a Task Plan
 
 <expand name="getopt"
     arg1="ase-task-reboot"
-    arg2="--next|-n=(none|DONE|EDIT|IMPLEMENT|PREFLIGHT)... --int-reuse-task">
+    arg2="--next|-n=(none|DONE|EDIT|IMPLEMENT|DRAFT)... --int-reuse-task">
     $ARGUMENTS
 </expand>
 
 <objective>
 *Reboot* the task plan by crafting it from scratch,
-based on the existing *WHAT* and *WHY*.
+based on the existing `SPECIFICATION (WHAT)`.
 </objective>
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-meta.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-common-task.md
 
 Procedure
@@ -55,8 +56,7 @@ Procedure
         <expand name="task-load-content"></expand>
 
     2.  <if condition="<task-content/> is empty">
-        Complain and tell the user to use the `ase-code-resolve`,
-        `ase-code-refactor`, `ase-code-craft`, or `ase-task-edit` skills
+        Complain and tell the user to use the `ase-task-edit` skill
         first to create a task plan. Then immediately stop processing
         this skill.
         </if>
@@ -66,58 +66,98 @@ Procedure
     1.  Start with <instruction></instruction> (set instruction to empty).
         Do not output anything.
 
-    2.  <if condition="<task-content/> contains neither '-   **WHAT**:' nor '-   **WHY**:'">
-        Set <instruction><task-content/></instruction> (set instruction to task content).
+    2.  <if condition="the `##  SPECIFICATION (WHAT)` section of <task-content/> contains at least one `DOM` or `IFC` bullet-point">
+        Set <mode>structured</mode>. Extract the <text/> of *every*
+        `DOM` and `IFC` bullet-point of the `##  SPECIFICATION (WHAT)`
+        section, in their original order, each with its
+        `-   <box/> <type/>:` prefix stripped and its wording kept
+        *verbatim*. Set <instruction/> to these texts, joined by a
+        blank line (set instruction to the extracted specification).
+        The `##  DESIGN (HOW)` and `##  VERIFICATION (WHEN)` sections
+        are *deliberately* ignored, as the reboot re-derives them from
+        scratch.
         </if>
 
-    3.  <if condition="<task-content/> contains '-   **WHAT**: <text/>'">
-        Set <instruction><text/></instruction> (set instruction to extracted text).
+    3.  <if condition="<instruction/> is still empty">
+        Set <mode>unstructured</mode>. The plan does not follow the
+        <format/> (or carries no `DOM` or `IFC` bullet-point), so the
+        reboot has to *file* its entire existing content into the
+        <format/> instead. Set <instruction/> to the full previous plan
+        "body" (the second block of <task-content/>, without frontmatter
+        and backmatter), with its wording kept *verbatim*.
         </if>
 
-    4.  <if condition="<task-content/> contains '-   **WHY**: <text/>' and <instruction/> is empty">
-        Set <instruction><text/></instruction> (set instruction to extracted text).
-        </if>
-
-    5.  <if condition="<task-content/> contains '-   **WHY**: <text/>' and <instruction/> is NOT empty">
-        Set <instruction><instruction/>, BECAUSE <text/></instruction>
-        (append extracted text to instruction).
-        </if>
-
-    6.  <if condition="the frontmatter of <task-content/> carries a `Created: <text/>` key">
+    4.  <if condition="the frontmatter of <task-content/> carries a `Created: <text/>` key">
         Set <timestamp-created><text/></timestamp-created> (set
         timestamp-created to extracted text).
         </if>
 
-    7.  <if condition="<instruction/> is empty or contains only whitespace">
-        The WHAT/WHY extraction yielded no usable text (e.g. a
-        `-   **WHAT**:` line existed but captured empty text, so the
-        whole-content fallback above did not fire). Fall back to the
-        full previous plan content: set <instruction><task-content/></instruction>
-        (set instruction to task content).
-        <if condition="<instruction/> is still empty or contains only whitespace">
-            There is nothing to reboot from. Only output the following
-            <template/> and then immediately *STOP* processing the entire
-            current skill:
+    5.  <if condition="<instruction/> is empty or contains only whitespace">
+        There is nothing to reboot from. Only output the following
+        <template/> and then immediately *STOP* processing the entire
+        current skill:
 
-            <template>
-            ⧉ **ASE**: ☻ skill: **ase-task-reboot**, ▶ ERROR: empty instruction -- nothing to reboot from
-            </template>
-        </if>
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-task-reboot**, ▶ ERROR: empty instruction -- nothing to reboot from
+        </template>
         </if>
 
-    8.  Only output the following <template/> and continue processing:
+    6.  Only output the following <template/> and continue processing:
 
         <template>
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ⇌ instruction: **<instruction/>**, ▶ status: **instruction given**
         </template>
 
-    9.  Create a new plan from scratch and store the result as
+    7.  <expand name="task-ground-plan" arg1=""/>
+
+        Create a new plan from scratch and store the result as
         <task-content/> by closely following the defined plan format
         <format/> and injecting into it all the information from
-        the <instruction/> and all decisions you derived from the
-        <instruction/>.
-
-    10. <expand name="task-save-content" arg1="plan rebooted"></expand>
+        the <instruction/>, all decisions you derived from the
+        <instruction/>, and the grounding in the project, where:
+
+        -   <if condition="<mode/> is `structured`">
+            the `##  SPECIFICATION (WHAT)` section is *seeded* by the
+            extracted `DOM` and `IFC` bullet-points, re-phrased and
+            re-structured where the <instruction/> demands it, and the
+            `##  DESIGN (HOW)` and `##  VERIFICATION (WHEN)` sections
+            are *re-derived* from scratch,
+            </if>
+        -   <if condition="<mode/> is `unstructured`">
+            *all* existing content of the <instruction/> is *filed* into
+            the `##  SPECIFICATION (WHAT)`, `##  DESIGN (HOW)`, and
+            `##  VERIFICATION (WHEN)` sections: classify each existing
+            statement, prose paragraph, bullet, or list item by its
+            nature into a `DOM`, `IFC`, `ARC`, `IMP`, `REG`, or `CON`
+            bullet-point, keep its wording as *verbatim* as the
+            bullet-point <text/> conventions allow, *never* drop a
+            distinct statement, and *add* missing `DOM`/`IFC`,
+            `ARC`/`IMP`, and `REG`/`CON` bullet-points *derived* from
+            the existing content where a section would otherwise stay
+            empty,
+            </if>
+        -   every bullet-point starts in the `[ ]` todo state,
+        -   the `Status:` frontmatter key is *reset* to the *default*
+            state of the task lifecycle model
+            <ase-project-task-lifecycle/>, as the rebooted plan starts
+            its lifecycle anew,
+        -   the frontmatter keys `Group:`, `Phase:`, `After:`, `Assignee:`,
+            `Kind:`, and `Tags:` are taken over from the previous plan *verbatim*
+            where present, except that all `grilled:` tags
+            are *dropped* from `Tags:` (the whole key is dropped if no
+            other tag remains), as the grilled plan content is gone,
+        -   the `Kind:` frontmatter key, if *absent* in the previous plan,
+            is *created* by *inferring* the kind of change from the
+            *re-created* plan content according to the plan <format/>
+            (defaulting to `CRAFTING`),
+        -   the frontmatter keys `Source:`, `Changeset:`, and `Target:`
+            are *dropped*, so they are *reset* to their configured
+            defaults according to the plan <format/>, as the rebooted
+            plan starts its change set flow anew, and
+        -   the entire "backmatter" of the previous plan is passed
+            through *verbatim*.
+
+    8.  <expand name="task-save-content" arg1="plan rebooted"></expand>
 
 4.  **Decide Next Step:**
 
@@ -125,12 +165,12 @@ Procedure
 
         <expand name="task-next-select"
             arg1="ase-task-reboot"
-            arg2="DONE|EDIT|IMPLEMENT|PREFLIGHT">
+            arg2="DONE|EDIT|IMPLEMENT|DRAFT">
             Next Step: How would you like to proceed with the plan?
             DONE: Stop processing.
             EDIT: Hand off plan to editing.
             IMPLEMENT: Hand off plan to implementation.
-            PREFLIGHT: Hand off plan to pre-flighting.
+            DRAFT: Hand off plan to implementation drafting.
         </expand>
 
     2.  Check the tool <result/> and dispatch accordingly:
@@ -150,7 +190,8 @@ Procedure
             <expand name="task-next-handoff" arg1="ase-task-implement"
                 arg2="plan rebooted -- hand-off to implementation"></expand>
 
-        -   If <result/> is `PREFLIGHT`:
-            <expand name="task-next-handoff" arg1="ase-task-preflight"
-                arg2="plan rebooted -- hand-off to pre-flight"></expand>
+        -   If <result/> is `DRAFT`:
+            <expand name="task-next-handoff" arg1="ase-task-implement"
+                arg2="plan rebooted -- hand-off to implementation draft"
+                arg3="--draft"></expand>