@rse/ase 2.0.6 → 2.0.7

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

@@ -227,10 +227,18 @@ related to this MCP call except the following <template/>:
     custom dialog according to the expanded `custom-dialog`
     definition. You *MUST* closely follow this definition:
 
-    <expand name="custom-dialog" arg1="--no-other">
+    <expand name="custom-dialog" arg1="--other">
         <content/>
     </expand>
 
+    If <result/> matches `OTHER: <text/>`, the user typed a free-text
+    request instead of choosing an option: treat it as an implicit
+    `DONE`, i.e., set <result>DONE</result>, and let the calling skill
+    finish along its `DONE` dispatch (output its `DONE` template).
+    Its *STOP* then ends only the skill, *not* the current turn:
+    immediately afterwards, handle <text/> as a regular user request,
+    outside of any skill, without re-opening this dialog.
+
 </define>
 
 <define name="task-next-handoff">

package/plugin/meta/ase-control.md

@@ -187,3 +187,17 @@ Control Flow Constructs
     the order of their occurrence in <parallel-body/>. This construct is
     expanded to its <parallel-body/>. Do not output anything else.
 
+-   *IMPORTANT*: You *MUST* honor the following rule for *all*
+    concurrently dispatched sub-agents -- whether invoked through
+    <parallel/> or through multiple `Agent` tool invocations emitted in
+    one single message:
+
+    The agent tool may run sub-agents in the *background* (e.g.
+    *Anthropic Claude Code CLI* ignores `run_in_background: false`) and
+    then notifies you of each returned sub-agent individually. While
+    these notifications arrive, you *MUST* *NOT* output anything -- no
+    progress messages (like `Batch 3 of 8 is back, 5 still running`),
+    no intermediate results, and no waiting notices -- but silently wait
+    for the remaining sub-agents. Only once *all* of them have returned,
+    continue with the processing which consumes their results.
+

package/plugin/meta/ase-format-specbook.yaml

@@ -125,7 +125,7 @@
   id: DG
   file: 03-REQS-DG-Domain-Glossary.md
   desc: >
-    The ubiquitous language of the domain, defining the meaning of each domain term in business language, together with its synonyms, its place in the hierarchy of terms, and the terms it has to be kept apart from, shared consistently across all Artifacts.
+    The ubiquitous language of the domain, defining the meaning of each domain term in business language, together with its synonyms, its place in the hierarchy of terms, and the terms it has to be kept apart from, shared consistently across all artifacts.
   optional: true
   children:
     - kind: TERM
@@ -581,7 +581,7 @@
           optional: true
         - name: TRIGGER
           desc: >
-            The event that starts the use case, stated as a 1-sentence occurrence (e.g. `The attendee opens the event URL.`), as opposed to the `PRE-CONDITION` which is a state that has to hold, and matching the `When <trigger>` of the event-driven Functional Requirements the use case exercises.
+            The event that starts the use case, stated as a 1-sentence occurrence (e.g. `The attendee opens the event URL.`), as opposed to the `PRE-CONDITION`, which is a state that has to hold, and matching the `When <trigger>` of the event-driven Functional Requirements the use case exercises.
           optional: true
         - name: POST-CONDITION
           desc: >
@@ -847,7 +847,7 @@
             The kind of the interface, one of:
             -   `REST`:      HTTP resources addressed by URL paths and HTTP methods.
             -   `GraphQL`:   A GraphQL schema of queries, mutations, and subscriptions.
-            -   `gRPC`:      Protocol Buffers based remote procedure calls.
+            -   `gRPC`:      Protocol Buffers-based remote procedure calls.
             -   `WebSocket`: Messages exchanged over a WebSocket connection.
             -   `MQTT`:      Messages published to and subscribed from MQTT topics.
             -   `MCP`:       Tools, resources, and prompts of a Model Context Protocol server.
@@ -1322,7 +1322,7 @@
       props:
         - name: MAXIMS
           desc: >
-            Comma-separated references to the MAXIM objects the principle concretizes (e.g. a `Stateless Services` principle concretizing a `Scale Out over Scale Up` maxim), so that the principles form a hierarchy below the maxims rather than a flat catalogue; omitted for a principle standing on its own forces alone.
+            Comma-separated references to the MAXIM objects the principle concretizes (e.g. a `Stateless Services` principle concretizing a `Scale Out over Scale Up` maxim), so that the principles form a hierarchy below the maxims rather than a flat catalog; omitted for a principle standing on its own forces alone.
           value: list([[MAXIM:*]])
           optional: true
         - name: DRIVEN-BY
@@ -1362,7 +1362,7 @@
           optional: true
         - name: USES
           desc: >
-            Comma-separated references to the smaller ARCHITECTURE-PATTERNS objects the pattern is composed of (e.g. a `Saga` using a `Transactional Outbox` for its steps), so that the patterns form a language of related structures rather than a flat catalogue.
+            Comma-separated references to the smaller ARCHITECTURE-PATTERNS objects the pattern is composed of (e.g. a `Saga` using a `Transactional Outbox` for its steps), so that the patterns form a language of related structures rather than a flat catalog.
           value: list([[PATTERN:*]])
           optional: true
           acyclic: true
@@ -1663,7 +1663,7 @@
           desc: >
             A single technology component, named with a short (2-5 word) summary (e.g. `UI Framework`, `Web Server`, `Relational Database`) and described in a concise (1-3 sentence) paragraph by how the product is used within the solution and how it fits into the overall technology stack, plus a 1-sentence rationale ("why") for choosing this product over the alternatives.
 
-            A component states one product in one role on one tier: the product used by several tiers alike belongs to the `Common` tier once, the lock-in carrying trade-off behind the choice is a Design Decisions decision referencing the component through `DECIDES`, and the functional components depending on the product reference it through `USED-BY`.
+            A component states one product in one role on one tier: the product used by several tiers alike belongs to the `Common` tier once, the lock-in-carrying trade-off behind the choice is a Design Decisions decision referencing the component through `DECIDES`, and the functional components depending on the product reference it through `USED-BY`.
           props:
             - name: PRODUCT
               desc: >
@@ -2395,7 +2395,7 @@
           optional: true
         - name: USES
           desc: >
-            Comma-separated references to the smaller CODE-PATTERNS objects the pattern is composed of (e.g. an `Endpoint Authorization` using the `Error Propagation` for its rejections), so that the patterns form a language of related shapes rather than a flat catalogue.
+            Comma-separated references to the smaller CODE-PATTERNS objects the pattern is composed of (e.g. an `Endpoint Authorization` using the `Error Propagation` for its rejections), so that the patterns form a language of related shapes rather than a flat catalog.
           value: list([[CODE-PATTERN:*]])
           optional: true
           acyclic: true
@@ -2449,8 +2449,8 @@
             The mandatory, concrete input data or action applied during the test, i.e. the stimulus whose response the `EXPECTED` judges.
         - name: EXPECTED
           desc: >
-            The mandatory, concrete, observable response of the solution to the `INPUT` (a message shown, a session issued, a submission rejected) that defines a passing test, as opposed to the `POST-CONDITION` which is the state left behind. When the test case verifies a NON-FUNCTIONAL-REQUIREMENTS object, the expected response restates the `METRIC` threshold of that requirement as the pass criterion (e.g. `p95 latency < 200 ms`) rather than a qualitative phrase (e.g. `remains responsive`).
+            The mandatory, concrete, observable response of the solution to the `INPUT` (a message shown, a session issued, a submission rejected) that defines a passing test, as opposed to the `POST-CONDITION`, which is the state left behind. When the test case verifies a NON-FUNCTIONAL-REQUIREMENTS object, the expected response restates the `METRIC` threshold of that requirement as the pass criterion (e.g. `p95 latency < 200 ms`) rather than a qualitative phrase (e.g. `remains responsive`).
         - name: POST-CONDITION
           desc: >
-            The persisted state that must hold after the test completes (e.g. `the authorization token is in state used`), including the state that must not have changed (e.g. `no session token exists`), as opposed to the `EXPECTED` which is the immediate response, and omitted for a test whose input leaves no state behind.
+            The persisted state that must hold after the test completes (e.g. `the authorization token is in state used`), including the state that must not have changed (e.g. `no session token exists`), as opposed to the `EXPECTED`, which is the immediate response, and omitted for a test whose input leaves no state behind.
           optional: true

package/plugin/meta/ase-skill.md

@@ -232,6 +232,13 @@ Skill Identification
     ⧉ **ASE**: ✪ skill: **<skill-name/>**, ✦ purpose: **<purpose/>**, ▶ status: **skill started**
     </template>
 
+    You *MUST* output this <template/> *immediately* as the *very first*
+    output of the skill, *before* any tool call (including the
+    `ase_getopt` call) and *before* any work of the skill, and also when
+    the skill was invoked via the `Skill` tool from another skill. Any
+    "Do not output anything" instruction of the subsequent steps does
+    *NOT* suppress or defer it.
+
     Later (but only if ((`$1` is *NOT* equal to `-h` or `--help`) *AND*
     (<ase-guidance-level/> is equal to `normal` or `verbose`))), once
     this skill finally will stop processing, you *MUST* once output the

package/plugin/mods/ase-mods-help-hint.ts

@@ -29,7 +29,7 @@ const GROUP  = /\[(?:[^[\]]|\[[^\]]*\])*\]|\((?:[^()]|\([^)]*\))*\)|\S+/g
 const NBSP   = String.fromCodePoint(0xA0)
 const SYNTAX = "gray"
 const REFER  = "red"
-const INDENT = 4
+const INDENT = 2
 const TITLE  = "[ ⧉ ASE: Show Skill Synopsis ]"
 
 /*  a hint band: the scroll state of its frame, the skill command as typed,

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

@@ -1,6 +1,6 @@
 ---
 name: ase-code-edit
-argument-hint: "[--help|-h] [--mode|-m auto|craft|refactor|resolve] [--approach|-a] [--grill|-g] [--grill-rounds|-r <n>] [--grill-until|-u MUST|SHOULD|MAY] [--grill-perspective|-p <perspective>] [--grill-ground|-G] [--verify|-v] [--worktree|-w <name>[:<branch>]] [--loop|-l] [<query>|<issue-id>]"
+argument-hint: "[--help|-h] [--mode|-m auto|craft|refactor|resolve] [--approach|-a] [--grill|-g] [--grill-rounds|-r <n>] [--grill-until|-u MUST|SHOULD|MAY] [--grill-perspective|-p <perspective>] [--grill-ground|-G] [--verify|-v light|none|full] [--worktree|-w <name>[:<branch>]] [--loop|-l] [<query>|<issue-id>]"
 description: >
     Edit Source Code: Use when the user wants to "edit" the code base in
     one shot from a query or a bare analyzer issue id like "P1", fusing
@@ -22,7 +22,7 @@ Edit Source Code
 
 <expand name="getopt"
     arg1="ase-code-edit"
-    arg2="--mode|-m=(auto|craft|refactor|resolve) --approach|-a --grill|-g --grill-rounds|-r=1 --grill-until|-u=(MUST|SHOULD|MAY) --grill-perspective|-p= --grill-ground|-G --verify|-v --worktree|-w= --loop|-l">
+    arg2="--mode|-m=(auto|craft|refactor|resolve) --approach|-a --grill|-g --grill-rounds|-r=1 --grill-until|-u=(MUST|SHOULD|MAY) --grill-perspective|-p= --grill-ground|-G --verify|-v=(light|none|full) --worktree|-w= --loop|-l">
     $ARGUMENTS
 </expand>
 
@@ -238,11 +238,18 @@ empty <todo-what/> or <todo-how/> renders as `(none)`:
                 arg3="file and directory paths, identifiers, symbols, types, commands, options, configuration keys, and literal values"
                 arg4="the code base"
                 arg5="">
-                <if condition="<getopt-option-verify/> is not equal `true`">
+                <if condition="<getopt-option-verify/> is equal `none`">
                 Raise *no* questions at all of focus area `REGRESSION`
-                or `CONFIRMATION`, as without `--verify` no verification
-                takes place which could honor their decisions.
-                </if></expand>
+                or `CONFIRMATION`, as under `--verify none` no
+                verification takes place which could honor their
+                decisions.
+                </if>
+                <elseif condition="<getopt-option-verify/> is equal `light`">
+                Raise *no* questions at all of focus area
+                `CONFIRMATION`, as under `--verify light` no
+                change-specific tests take place which could honor
+                their decisions.
+                </elseif></expand>
 
             If <grill-stop/> is `true`, skip the remaining items of
             this round and all remaining rounds, and continue with
@@ -388,27 +395,57 @@ empty <todo-what/> or <todo-how/> renders as `(none)`:
 
 7.  **State: verifying:**
 
-    Enter this state only if <getopt-option-verify/> is equal `true`.
-    Otherwise you *MUST* *strictly skip* the entire state and *any*
-    verification: do *NOT* run any build, tests, linter, or
-    type-checker, and do *NOT* execute the modified program.
+    Enter this state only if <getopt-option-verify/> is equal `light` or
+    `full`. Otherwise (`none`) you *MUST* *strictly skip* the entire
+    state and *any* verification: do *NOT* run any build, tests, linter,
+    or type-checker, and do *NOT* execute the modified program.
 
     1.  Verify whether the implementation fulfills <todo-what/> and
-        <todo-how/> by running available verification commands
-        (build, tests, linter, type-checker)
+        <todo-how/>
         <if condition="<worktree-dir/> is not empty">
-        , each with <worktree-dir/> as its working directory
-        </if>.
+        , running every command with <worktree-dir/> as its working
+        directory
+        </if>:
+
+        -   Under `light` and `full`: run the available lint and build
+            commands (including the type-checker) and the already
+            existing regression test suite, if any.
+
+        -   Under `full` only: additionally perform *individual*,
+            *change-specific* manual tests, which exercise the changed
+            behavior through ad-hoc scratch tests and program runs.
+            Clean up all scratch test files afterwards, so they never
+            become part of the change set.
 
         If the verification fails, you *MUST* *adjust* the failing parts
-        of the change set and *RE-VERIFY* until the verification passes!
+        of the change set and *RE-VERIFY* -- for at most *ten* rounds
+        in total.
+
+    2.  <if condition="the verification still fails after the last round">
+
+        Only output the following <template/>, listing one bullet line
+        per remaining failure:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-code-edit**, ▶ status: **verification failed**
 
-    2.  Only output the following <template/>:
+        <ase-tpl-bullet-signal/> **REMAINING FAILURES**:
+
+        -   <failure/>
+        [...]
+        </template>
+
+        </if>
+        <else>
+
+        Only output the following <template/>:
 
         <template>
         ⧉ **ASE**: ✪ skill: **ase-code-edit**, ▶ status: **verification passed**
         </template>
 
+        </else>
+
 8.  **Loop or Finish:**
 
     <if condition="<getopt-option-loop/> is equal `true`">

package/plugin/skills/ase-code-edit/help.md

@@ -14,7 +14,7 @@
     [`--grill-until`|`-u` `MUST`|`SHOULD`|`MAY`]
     [`--grill-perspective`|`-p` *perspective*]
     [`--grill-ground`|`-G`]
-    [`--verify`|`-v`]
+    [`--verify`|`-v` `light`|`none`|`full`]
     [`--worktree`|`-w` *name*[`:`*branch*]]
     [`--loop`|`-l`]
     [*query*]
@@ -34,7 +34,8 @@ parts), *discovering* (read the source artifacts related to the query),
 *grilling* (optionally stress-test the query with rounds of questions),
 *implementing* (optionally select an approach, then apply the change
 set in place, honoring the tenet set selected via `--mode`), and
-*verifying* (optionally verify the implementation until it passes). The
+*verifying* (verify the implementation until it passes, unless
+disabled via `--verify none`). The
 *querying* state, every *grilling* round, and the approach selection
 close with an `EDIT TODO` box showing the established `WHAT` and `HOW`
 information.
@@ -69,8 +70,9 @@ information.
     of a round are sorted by descending focus area importance
     (`DOMAIN`, `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`,
     `REGRESSION`, `CONFIRMATION`). Questions of focus area
-    `REGRESSION` and `CONFIRMATION` are raised only together with
-    `--verify`, as only then a verification honors their decisions.
+    `REGRESSION` are raised only under `--verify light` or `full`, and
+    those of focus area `CONFIRMATION` only under `--verify full`, as
+    only then a verification honors their decisions.
     All questions of a round are announced together below a
     `GRILLING ROUND K/L` line (the round numbering is omitted when only
     a single round is performed) as a `QUESTION`/`ANSWERS` table with
@@ -130,12 +132,17 @@ information.
     no usable facts are found, a warning is shown and the grilling falls
     back to model knowledge. Only effective together with `--grill`.
 
--   `--verify`|`-v`:
-    Verify whether the implementation fulfills the requirements, by
-    running the available verification commands (build, tests, linter,
-    type-checker) and adjusting the failing parts of the change set
-    until the verification passes. Without `--verify`, strictly no
-    verification is performed at all.
+-   `--verify`|`-v` `light`|`none`|`full`:
+    Verify whether the implementation fulfills the requirements, and
+    adjust the failing parts of the change set until the verification
+    passes, for at most ten rounds, listing any failures remaining after
+    the last round as `REMAINING FAILURES`. The default `light` runs the
+    available lint and build commands (including the type-checker) and
+    the already existing regression test suite, if any. The level `full`
+    additionally performs individual, change-specific manual tests
+    through ad-hoc scratch tests and program runs, which are cleaned up
+    afterwards. The level `none` strictly performs no verification at
+    all.
 
 -   `--worktree`|`-w` *name*[`:`*branch*]:
     Apply the change sets inside the dedicated Git worktree
@@ -176,16 +183,22 @@ information.
 
 ##  EXAMPLES
 
-Edit in one shot, without any questions or verification:
+Edit in one shot, without any questions, but with light verification:
 
 ```text
 ❯ /ase-code-edit add a --verbose option to the CLI
 ```
 
-Grill the query with two rounds first, then implement and verify:
+Edit in one shot, without any questions or verification:
+
+```text
+❯ /ase-code-edit -v none add a --verbose option to the CLI
+```
+
+Grill the query with two rounds first, then implement and fully verify:
 
 ```text
-❯ /ase-code-edit -g -r 2 -v refactor the config loading into layers
+❯ /ase-code-edit -g -r 2 -v full refactor the config loading into layers
 ```
 
 Let the user pick one of several resolution approaches first, then

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

@@ -10,6 +10,7 @@ effort: high
 allowed-tools:
     - "Bash(git rev-parse *)"
     - "Bash(git -C *)"
+    - "Bash(find *)"
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
@@ -123,8 +124,9 @@ related to a set of code quality aspects.
     `<repo-root/>/`. If `<getopt-arguments/>` is not empty, keep only
     those files which lie within the source code referenced by it,
     expanding any directory or wildcard references with the `Glob`
-    tool. Set <sources/> to the resulting list of individual source
-    code files, preserving order.
+    tool (or, if the `Glob` tool is not available, with the `find`
+    command via the `Bash` tool). Set <sources/> to the resulting list
+    of individual source code files, preserving order.
 
     If <sources/> is empty, only output the following <template/>
     and then *SKIP* the rest of this STEP 1 and the remaining steps
@@ -139,7 +141,9 @@ related to a set of code quality aspects.
 
     For this, first *silently* resolve `<getopt-arguments/>` to the
     list <sources/> of individual source code files, expanding any
-    directory or wildcard references with the `Glob` tool.
+    directory or wildcard references with the `Glob` tool (or, if the
+    `Glob` tool is not available, with the `find` command via the
+    `Bash` tool).
 
     If <sources/> is empty (no *source-reference* given or none of it
     resolvable), only output the following <template/> and then *STOP*