@rse/ase 0.9.53 → 0.9.54

package/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "https://ase.tools",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "https://github.com/rse/ase/issues" },
-    "version":                              "0.9.53",
+    "version":                              "0.9.54",
     "license":                              "Apache-2.0",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -31,7 +31,7 @@
         "shx":                              "0.4.0",
 
         "@types/node":                      "26.1.2",
-        "@types/luxon":                     "3.7.2",
+        "@types/luxon":                     "3.7.3",
         "@types/which":                     "3.0.4",
         "@types/update-notifier":           "6.0.8",
         "@types/shell-quote":               "1.7.5",

package/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.9.53",
+    "version":     "0.9.54",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.9.53",
+    "version":     "0.9.54",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.9.53",
+    "version":     "0.9.54",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/meta/ase-common-code.md

@@ -0,0 +1,34 @@
+
+Code Skill Common Steps
+=======================
+
+<define name="code-tenets">
+
+You *MUST* internalize and strictly honor the **GENERIC TENETS**, and
+the **<arg1/> TENETS** of the **ASE Tenets** in the following creation
+and updating of code. Do not output anything.
+
+</define>
+
+<define name="code-tenets-from-plan">
+
+Determine the *kind of change* the task plan describes and internalize
+the corresponding tenet sets:
+
+-   If <task-content/> contains a `☯   Kind:     <text/>` header line
+    and <text/> is one of `CRAFTING`, `REFACTORING`, or `RESOLVING`:
+    Set <task-kind><text/></task-kind> (set task kind to the stated kind).
+
+-   Else:
+    The plan states no kind at all, or an unrecognized one, so *infer*
+    the kind from the plan content itself: `RESOLVING` if the plan
+    predominantly fixes a defect, `REFACTORING` if it predominantly
+    re-structures existing artifacts without changing their observable
+    behavior, and `CRAFTING` otherwise. Set <task-kind/> to the inferred
+    kind, defaulting to `CRAFTING` if the inference stays inconclusive.
+
+Then honor the tenet sets of <task-kind/>:
+
+<expand name="code-tenets" arg1="<task-kind/>"></expand>
+
+</define>

package/plugin/meta/ase-constitution.md

@@ -14,12 +14,16 @@ which boosts you to an expert-level Software Engineering AI agent.
 - Do *not* insist on early "return" in "if" blocks, if an "else" block exists.
 - Do *not* remove any whitespace in the code formatting -- keep whitespace aligned with code base.
 - Do *not* produce any trailing white-spaces on any lines.
+- Do *not* guess missing tool call parameters or fill them with invented placeholder values.
 
 ## Commandments
 
 - Be *honest* and *transparent* in all your responses.
 - *Ground* factual and technical claims in verifiable evidence (code base, local files, or web)
   with a reference, rather than unverified model knowledge; state explicitly when a claim cannot be verified.
+- Assume your *internal knowledge of dependencies* (libraries, frameworks, tools, and their implementations)
+  is *outdated*; always verify the current API, version, and usage pattern against the local sources
+  or the web before writing any code against them.
 - Before proposing any code changes, explain *WHAT* the proposed changes do and *WHY* it is necessary.
 - Use *concise* and *type-safe code* only.
 - Use *precise* and *surgical code changes* only.
@@ -37,7 +41,8 @@ which boosts you to an expert-level Software Engineering AI agent.
 - Use *double-quotes* (`"[...]"`) instead of single-quotes (`'[...]'`) for all strings.
 - Use K&R coding style with *opening braces* at the end of lines and *closing braces* at the beginning of lines.
 - When a language has a *more strongly-typed variant*, prefer that variant.
-- When generating temporary helper programs, prefer the *target project's primary programming language*.
+- When generating temporary helper programs or scratch test files, prefer the *target project's primary
+  programming language* and *clean them up* once they are no longer needed.
 
 @./ase-persona.md
 

package/plugin/meta/ase-format-task.md

@@ -10,6 +10,7 @@ Every *task* uses a strict and fixed format:
 
 ⎈   Created:  <timestamp-created/>
 ⚙   Modified: <timestamp-modified/>
+☯   Kind:     <task-kind/>
 
 ##  CONTEXT
 
@@ -49,6 +50,20 @@ You *MUST* honor the following hints on this *task* format:
 -   The <task-id/> has to be substituted with the current value of
     <ase-task-id/> in the current session context.
 
+-   The `☯   Kind:` line states the *kind of change* the task plan
+    describes, and hence which *operation-specific tenet set* of the
+    **ASE Tenets** a subsequent preflight or implementation has to
+    honor. The <task-kind/> value is *strictly* one of `CRAFTING`,
+    `REFACTORING`, or `RESOLVING`, and the line is column-aligned with
+    the `⎈   Created:` and `⚙   Modified:` lines above it.
+
+-   The `☯   Kind:` line is *optional*: a skill *authoring* or
+    *updating* a task plan *CAN* update an already present line or pass
+    it through *verbatim* and *MAY* create a missing one by *inferring*
+    the kind from the plan content (defaulting to `CRAFTING`). A
+    `--dry` run *never* drops this line, as `--dry` only omits the
+    `##  VERIFICATION` section.
+
 -   The <timestamp-created/> is the timestamp when this task plan was
     created. The <timestamp-modified/> is the timestamp when this
     task plan was last modified. Both use an ISO-style format

package/plugin/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "https://ase.tools",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "https://github.com/rse/ase/issues" },
-    "version":                              "0.9.53",
+    "version":                              "0.9.54",
     "license":                              "Apache-2.0",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

package/plugin/skills/ase-code-craft/SKILL.md

@@ -40,6 +40,7 @@ From scratch *craft* the following feature:
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
 
 Procedure
 ---------
@@ -127,11 +128,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Crafting Tenets">
 
-    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
-        and the **CRAFTING TENETS** of the **ASE Tenets** when updating
-        in the following. Do not output anything.
+    1.  <task-kind>CRAFTING</task-kind>
 
-    2.  Do not output anything in this STEP 3.
+    2.  <expand name="code-tenets" arg1="<task-kind/>"></expand>
+
+    3.  Do not output anything in this STEP 3.
 
     </step>
 
@@ -251,9 +252,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
     2.  Call the `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the
         `ase` MCP server and use the `text` field of its response for
         <timestamp-created/> and <timestamp-modified/> information. Then
-        insert the current <ase-task-id/>, <timestamp-created/>, and
-        <timestamp-modified/> information and calculate the number of
-        words <words/> of <task-content/>.
+        insert the current <ase-task-id/>, <timestamp-created/>,
+        <timestamp-modified/>, and <task-kind/> information and calculate
+        the number of words <words/> of <task-content/>.
 
     3.  You then *MUST* *save* the resulting plan content with the
         `ase_task_save(id: "<ase-task-id/>", text: "<task-content/>")`.

package/plugin/skills/ase-code-refactor/SKILL.md

@@ -40,6 +40,7 @@ to `true`, <getopt-option-dry/> to `true`, and <getopt-option-next/> to
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
 
 Procedure
 ---------
@@ -127,11 +128,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Refactoring Tenets">
 
-    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
-        and the **REFACTORING TENETS** of the **ASE Tenets** when updating
-        in the following. Do not output anything.
+    1.  <task-kind>REFACTORING</task-kind>
 
-    2.  Do not output anything in this STEP 3.
+    2.  <expand name="code-tenets" arg1="<task-kind/>"></expand>
+
+    3.  Do not output anything in this STEP 3.
 
     </step>
 
@@ -251,9 +252,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
     2.  Call the `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the
         `ase` MCP server and use the `text` field of its response for
         <timestamp-created/> and <timestamp-modified/> information. Then
-        insert the current <ase-task-id/>, <timestamp-created/>, and
-        <timestamp-modified/> information and calculate the number of
-        words <words/> of <task-content/>.
+        insert the current <ase-task-id/>, <timestamp-created/>,
+        <timestamp-modified/>, and <task-kind/> information and calculate
+        the number of words <words/> of <task-content/>.
 
     3.  You then *MUST* *save* the resulting plan content with the
         `ase_task_save(id: "<ase-task-id/>", text: "<task-content/>")`.

package/plugin/skills/ase-code-resolve/SKILL.md

@@ -40,6 +40,7 @@ to `true`, <getopt-option-dry/> to `true`, and <getopt-option-next/> to
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
 
 Procedure
 ---------
@@ -181,11 +182,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Problem Resolution Tenets">
 
-    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
-        and the **RESOLVING TENETS** of the **ASE Tenets** when updating
-        in the following. Do not output anything.
+    1.  <task-kind>RESOLVING</task-kind>
 
-    2.  Do not output anything in this STEP 3.
+    2.  <expand name="code-tenets" arg1="<task-kind/>"></expand>
+
+    3.  Do not output anything in this STEP 3.
 
     </step>
 
@@ -305,9 +306,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
     2.  Call the `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the
         `ase` MCP server and use the `text` field of its response for
         <timestamp-created/> and <timestamp-modified/> information. Then
-        insert the current <ase-task-id/>, <timestamp-created/>, and
-        <timestamp-modified/> information and calculate the number of
-        words <words/> of <task-content/>.
+        insert the current <ase-task-id/>, <timestamp-created/>,
+        <timestamp-modified/>, and <task-kind/> information and calculate
+        the number of words <words/> of <task-content/>.
 
     3.  You then *MUST* *save* the resulting plan content with the
         `ase_task_save(id: "<ase-task-id/>", text: "<task-content/>")`.

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

@@ -1,6 +1,6 @@
 ---
 name: ase-task-implement
-argument-hint: "[--help|-h] [--next|-n <option>[,...]] [<id>]"
+argument-hint: "[--help|-h] [--next|-n <option>[,...]] [--worktree|-w] [<id>]"
 description: >
     Implement current or given task plan.
     Use when the user calls to "implement", "realize" or "apply" the
@@ -21,7 +21,7 @@ Implement a Task Plan
 
 <expand name="getopt"
     arg1="ase-task-implement"
-    arg2="--next|-n=(none|DONE|DELETE)... --int-reuse-task">
+    arg2="--next|-n=(none|DONE|DELETE)... --worktree|-w --int-reuse-task">
     $ARGUMENTS
 </expand>
 
@@ -32,6 +32,8 @@ with a corresponding, complete *change set*.
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-common-task.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
 
 Procedure
 ---------
@@ -59,7 +61,98 @@ Procedure
         or `ase-task-edit` skills first to create a task plan. Then
         immediately stop processing this skill.
 
-3.  **Create Implementation:**
+    3.  Internalize the tenets stated by the plan:
+
+        <expand name="code-tenets-from-plan"></expand>
+
+3.  **Prepare WorkTree:**
+
+    <if condition="<getopt-option-worktree/> is not equal `true`">
+    No worktree was requested, so the implementation is applied directly
+    to the *current* working copy. Set <worktree-dir></worktree-dir>
+    (empty) and *skip* all remaining sub-steps of this step. Do not
+    output anything.
+    </if>
+
+    1.  Set <worktree-name><ase-task-id/></worktree-name>. The worktree
+        is *never* named by an own option value: it always carries the
+        unique *task id*, so the worktree directory and its branch stay
+        unambiguously tied to the very task plan implemented in them.
+        The task id is a plain identifier by construction, hence it is
+        directly usable as both a directory and a branch name. Do not
+        output anything.
+
+    2.  Determine the *repository root* by running the corresponding
+        command (taken exactly as given) and capturing its output into
+        <repo-root/>:
+
+        `git rev-parse --show-toplevel`
+
+        <if condition="this command fails">
+        The current directory is no Git repository, so no worktree can be
+        created. Only output the following <template/> and then
+        immediately *STOP* processing the entire current skill, leaving
+        the working copy *untouched*:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-task-implement**, ▶ ERROR: no Git repository -- cannot create worktree
+        </template>
+        </if>
+
+        Then set <worktree-dir><repo-root/>/.ase/worktree/<worktree-name/></worktree-dir>.
+
+    3.  Determine the *existing worktrees* and *existing branches* by
+        running the corresponding commands (taken exactly as given) and
+        capturing their outputs:
+
+        `git worktree list --porcelain`
+
+        `git branch --list`
+
+        <if condition="the worktree directory <worktree-dir/> or the branch <worktree-name/> already exists">
+        Only output the following <template/> and then immediately *STOP*
+        processing the entire current skill, leaving the existing
+        worktree, its branch, and the working copy *untouched*:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ ERROR: worktree or branch **<worktree-name/>** already exists
+        </template>
+
+        Directly *after* this error <template/>, and *before* stopping,
+        give the corrective hint by expanding the following (which,
+        depending on the configured <ase-guidance-level/>, may expand
+        into nothing and hence emit no output at all):
+
+        <ase-tpl-hint level="minimal">
+        Remove the existing worktree via `git worktree remove` and `git branch -d`, or rename the task via `/ase-task-rename` to implement it under a still unused worktree name.
+        </ase-tpl-hint>
+        </if>
+
+    4.  Create the worktree by running the corresponding command (taken
+        exactly as given), which creates the directory *and* -- named
+        after its last path component -- the branch <worktree-name/> from
+        `HEAD`. The `.ase` directory is usually git-ignored, so the
+        worktree itself never shows up as a change:
+
+        `git worktree add "<worktree-dir/>"`
+
+        <if condition="this command fails">
+        Only output the following <template/> and then immediately *STOP*
+        processing the entire current skill, leaving the working copy
+        *untouched*:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ ERROR: worktree **<worktree-name/>** failed to create
+        </template>
+        </if>
+
+    5.  Only output the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ◉ worktree: **.ase/worktree/<worktree-name/>**, ▶ status: **worktree created**
+        </template>
+
+4.  **Create Implementation:**
 
     1.  Perform a *final implementation* of the task plan
         by modifying the *artifacts* with a corresponding, complete
@@ -73,6 +166,19 @@ Procedure
         overrules the implementation draft in the `IMPLEMENTATION DRAFT`
         section of <task-content/>.
 
+        <if condition="<worktree-dir/> is not empty">
+        The change set *MUST* land *exclusively inside* the worktree
+        <worktree-dir/>: resolve *every* file path of the task plan
+        relative to <worktree-dir/> instead of the original working copy,
+        and run *every* verification command (build, tests, linter,
+        type-checker, program execution) with <worktree-dir/> as its
+        working directory. You *MUST* *NEVER* modify, stage, stash,
+        revert, or commit anything *outside* of this worktree. Leave the
+        worktree *uncommitted*: do *not* run `git add` and do *not* run
+        `git commit`, so the user keeps full control over the final
+        commit.
+        </if>
+
         <if condition="<task-content/> does NOT contain a `##  VERIFICATION` section heading">
         The task plan deliberately *omits* the `##  VERIFICATION`
         section. You *MUST* therefore *strictly skip* the entire
@@ -89,7 +195,17 @@ Procedure
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan implemented**
         </template>
 
-4.  **Decide Next Step:**
+    3.  <if condition="<worktree-dir/> is not empty">
+        Give the closing hint by expanding the following (which,
+        depending on the configured <ase-guidance-level/>, may expand
+        into nothing and hence emit no output at all):
+
+        <ase-tpl-hint level="minimal">
+        The change set is uncommitted in `.ase/worktree/<worktree-name/>` on branch `<worktree-name/>` -- review and commit it there, then remove the worktree via `git worktree remove`.
+        </ase-tpl-hint>
+        </if>
+
+5.  **Decide Next Step:**
 
     1.  *Determine next step*:
 

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

@@ -8,6 +8,7 @@
 `ase-task-implement`
     [`--help`|`-h`]
     [`--next`|`-n` *option*[,...]]
+    [`--worktree`|`-w`]
     [*id*]
 
 ##  DESCRIPTION
@@ -18,6 +19,13 @@ a task plan by modifying the corresponding *artifacts* with a complete
 section produced by `ase-task-preflight` is used as a hint - the plain
 plan content always overrules the draft.
 
+The *kind of change* stated by the plan's `☯   Kind:` header line
+(`CRAFTING`, `REFACTORING`, or `RESOLVING`) selects which
+*operation-specific tenet set* of the **ASE Tenets** is internalized
+before any artifact is touched, in addition to the always applying
+**GENERIC TENETS**. If a plan carries no such line, the kind is
+*inferred* from the plan content, defaulting to `CRAFTING`.
+
 If the task plan deliberately *omits* the `##  VERIFICATION` section
 (as produced by `ase-code-craft`, `ase-code-refactor`,
 `ase-code-resolve`, or `ase-task-edit` when invoked with `--dry`),
@@ -25,6 +33,17 @@ the entire verification phase is strictly skipped: no build, tests,
 linter, type-checker, or program execution is performed once the
 source files have been modified.
 
+With `--worktree`|`-w`, the change set is *not* applied to the current
+working copy: a *fresh Git WorkTree* `.ase/worktree/<id>` and its
+equally named branch are created from `HEAD` *before* any artifact is
+touched, and the entire implementation -- including all verification
+runs -- then happens *inside* that worktree, which is left
+*uncommitted*. The worktree is *not* named by an option value: it
+always carries the unique *task id*, so worktree and branch stay tied
+to the very task plan implemented in them. As the worktree branches off
+`HEAD`, *uncommitted* changes of the current working copy are *not*
+carried over into it.
+
 After implementation, the user is asked whether to preserve or
 delete the task plan, unless `--next` pre-selects this choice.
 
@@ -40,6 +59,14 @@ delete the task plan, unless `--next` pre-selects this choice.
     answer required), `DONE` (preserve task plan and stop), or
     `DELETE` (hand off to `ase-task-delete`).
 
+`--worktree`|`-w`:
+    Apply the change set inside a dedicated *Git WorkTree* instead of
+    the current working copy. The worktree directory `.ase/worktree/<id>`
+    and its equally named branch are derived from the *task id* and
+    created from `HEAD`. If either the directory or the branch already
+    exists, the skill stops and touches nothing. By default, the change
+    set is applied to the current working copy.
+
 ##  ARGUMENTS
 
 *id*:
@@ -60,7 +87,15 @@ Implement a specific task and delete the plan when done:
 ❯ /ase-task-implement --next DELETE hello
 ```
 
+Implement the task `hello` inside the isolated Git WorkTree
+`.ase/worktree/hello`:
+
+```text
+❯ /ase-task-implement --worktree hello
+```
+
 ##  SEE ALSO
 
 [`ase-task-edit`](../ase-task-edit/help.md), [`ase-task-preflight`](../ase-task-preflight/help.md), [`ase-task-reboot`](../ase-task-reboot/help.md),
 [`ase-task-view`](../ase-task-view/help.md), [`ase-task-delete`](../ase-task-delete/help.md).
+

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

@@ -32,6 +32,8 @@ for a corresponding, *complete source code change set*.
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-common-task.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
 
 Procedure
 ---------
@@ -59,6 +61,10 @@ Procedure
         or `ase-task-edit` skills first to create a task plan. Then
         immediately stop processing this skill.
 
+    3.  Internalize the tenets stated by the plan:
+
+        <expand name="code-tenets-from-plan"></expand>
+
 3.  **Create Implementation Draft:**
 
     1.  Perform a *preflight* of the *implementation* of <task-content/> by creating a

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

@@ -19,6 +19,13 @@ draft for a corresponding, complete *artifact change set* in
 an `IMPLEMENTATION DRAFT` section (replacing any previous draft).
 No source files are modified.
 
+The *kind of change* stated by the plan's `☯   Kind:` header line
+(`CRAFTING`, `REFACTORING`, or `RESOLVING`) selects which
+*operation-specific tenet set* of the **ASE Tenets** is internalized
+before the draft is produced, in addition to the always applying
+**GENERIC TENETS**. If a plan carries no such line, the kind is
+*inferred* from the plan content, defaulting to `CRAFTING`.
+
 After the preflight, the user is asked whether to stop, hand
 off to `ase-task-edit`, or hand off to `ase-task-implement`,
 unless `--next` pre-selects this choice.