@rse/ase 0.9.55 → 0.9.57

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

@@ -4,7 +4,7 @@ Code Skill Common Steps
 
 <define name="code-tenets">
 
-You *MUST* internalize and strictly honor the **GENERIC TENETS**, and
+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.
 
@@ -32,3 +32,170 @@ Then honor the tenet sets of <task-kind/>:
 <expand name="code-tenets" arg1="<task-kind/>"></expand>
 
 </define>
+
+<define name="code-approaches">
+
+You *MUST* perform the following sub-steps *internally* and *without
+any output* until and including the recommendation decision. Only
+sub-steps 4-7 below are allowed to produce output; sub-steps 4-6 only if
+<getopt-option-auto/> is equal `false` *and* <ase-project-boxing/>
+is *not* equal `black`.
+
+If <getopt-option-auto/> is equal `true` or <ase-project-boxing/> is
+equal `black`, *skip* the reporting sub-steps 4-6 entirely (they
+perform no output at all) to speed up processing.
+
+1.  *Propose* a corresponding *<arg1/> approach*, optionally including
+    some *alternative* <arg1/> approaches. Do *not* output anything
+    in this sub-step.
+
+2.  *Reflect* on and *critique* the proposed approaches by deriving,
+    per approach, a small set of concrete *pros* and *cons*. Do
+    *not* output anything in this sub-step.
+
+3.  Based on the reflection, *decide* which approach to recommend
+    and annotate it with an <annotation/> of
+    ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
+    empty <annotation/>. Do *not* output anything in this sub-step.
+
+4.  Indicate start of reporting by showing the following <template/>:
+
+    <template>
+    <ase-tpl-head title="APPROACHES"/>
+    </template>
+
+5.  Now report each approach with the following <template/>,
+    inlining its pros/cons derived in sub-step 2, and do not output
+    anything else in this step:
+
+    <template>
+    ●   **APPROACH A<n/>**<annotation/>: **<summary/>**
+    ○   [...]
+    ⊕   *PRO*: [...]
+    ⊖   *CON*: [...]
+    </template>
+
+    Hints:
+
+    -   Give a short one-sentence <summary/> of the <arg1/> approach
+        plus *precise* and *ultra brief and concise* <arg1/>
+        information. Try to keep the number of bullet points
+        (`○ [...]`) in the range of 1-4.
+
+6.  Indicate end of reporting by showing the following <template/>:
+
+    <template>
+    <ase-tpl-foot title="APPROACHES"/>
+    </template>
+
+7.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
+
+    In the following, you *MUST* *NOT* use your built-in
+    <user-dialog-tool/> tool! Instead, you *MUST* just show a
+    custom dialog according to the expanded `custom-dialog`
+    definition. You *MUST* closely follow this definition.
+
+    Let the user choose the preferred approach A<n/> by raising
+    a question with the following custom dialog, where per
+    approach A<n/>, you determine an ultra brief summary
+    <short-summary/> and then use the answer option `A<n/>:
+    ⚝ **RECOMMENDATION** ⚝ - <short-summary/>` for your
+    recommended approach plus zero or more answer options `A<n/>:
+    <short-summary/>` for all other approaches:
+
+    <expand name="custom-dialog" arg1="--no-other">
+        Select Approach: Select your preferred <arg2/> approach to follow?
+        A<n/>: <short-summary/>
+        [...]
+    </expand>
+
+    </if>
+    <else>
+
+    Set <n/> to the number of the <arg1/> approach A<n/> you recommend.
+    Output a hint with the following <template/>:
+
+    <template>
+    ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
+    </template>
+
+    </else>
+
+</define>
+
+<define name="code-next-dispatch">
+
+Treat <getopt-option-next/> as a comma-separated chronological
+list of pre-selected next-step tokens. *Peek* the *first* token
+as <head/> (or `none` if the list is `none`/empty).
+Set <args>--int-reuse-task</args>.
+
+1.  <if condition="<head/> is equal `DONE`">
+    Consume the head: set <getopt-option-next/> to the remaining
+    tokens (joined back with `,`, or `none` if empty). `DONE`
+    means the freshly composed plan is finalized as-is, so do
+    *not* hand off to `ase-task-edit`. Only output the following
+    <template/> and then *STOP*. Do *not* implement the plan.
+
+    <template>
+    ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan finalized -- done**
+    </template>
+    </if>
+
+2.  <elseif condition="<head/> is equal `IMPLEMENT`">
+    Consume the head: set <getopt-option-next/> to the remaining
+    tokens (joined back with `,`, or `none` if empty).
+    <if condition="<getopt-option-next/> is not equal `none`">
+        Set <args><args/> --next <getopt-option-next/></args>
+    </if>
+    Call the tool `Skill(skill: "ase:ase-task-implement", args: "<args/>")`
+    to *implement* the freshly composed plan, bypassing `ase-task-edit`.
+    </elseif>
+
+3.  <elseif condition="<head/> is equal `PREFLIGHT`">
+    Consume the head: set <getopt-option-next/> to the remaining
+    tokens (joined back with `,`, or `none` if empty).
+    <if condition="<getopt-option-next/> is not equal `none`">
+        Set <args><args/> --next <getopt-option-next/></args>
+    </if>
+    Call the tool `Skill(skill: "ase:ase-task-preflight", args: "<args/>")`
+    to *preflight* the freshly composed plan, bypassing `ase-task-edit`.
+    </elseif>
+
+4.  <elseif condition="<head/> is equal `GRILL`">
+    Consume the head: set <getopt-option-next/> to the remaining
+    tokens (joined back with `,`, or `none` if empty). `GRILL`
+    is this skill's own dispatch token, *not* part of
+    `ase-task-grill`'s `--next` vocabulary, so it must be
+    stripped here rather than forwarded. All remaining tokens are
+    `ase-task-grill`'s own vocabulary and are forwarded verbatim.
+    <if condition="<getopt-option-next/> is not equal `none`">
+        Set <args><args/> --next <getopt-option-next/></args>
+    </if>
+    Call the tool `Skill(skill: "ase:ase-task-grill", args: "<args/>")`
+    to *grill* the freshly composed plan, bypassing `ase-task-edit`.
+    </elseif>
+
+5.  <else>
+    Hand off to `ase-task-edit`.
+    <if condition="<head/> is equal `EDIT`">
+        Consume the head: set <getopt-option-next/> to the remaining
+        tokens (joined back with `,`, or `none` if empty). `EDIT`
+        is this skill's own dispatch token, *not* part of
+        `ase-task-edit`'s `--next` vocabulary, so it must be
+        stripped here rather than forwarded.
+    </if>
+    All remaining tokens are `ase-task-edit`'s own vocabulary
+    and are forwarded verbatim, so `ase-task-edit` consumes its
+    own head itself.
+    <if condition="<getopt-option-next/> is not equal `none`">
+        Set <args><args/> --next <getopt-option-next/></args>
+    </if>
+    Then call the tool `Skill(skill: "ase:ase-task-edit", args: "<args/>")`.
+    </else>
+
+6.  In every branch above which invoked the `Skill` tool, you *MUST*
+    immediately stop processing the current skill once the `Skill`
+    tool was used.
+
+</define>

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

@@ -62,29 +62,30 @@ Task Skill Common Steps
 
 <if condition="
     <getopt-option-int-reuse-task/> is equal `true`
-    *and* a `ase_task_save(id: '<ase-task-id/>', ...)` tool call
+    *and* an `ase_task_save(id: '<ase-task-id/>', ...)` tool call
     exists earlier in the current session
 ">
-    Set <text/> to the `text` *output* field of the most recent
+    Set <text/> to the `text` *argument* of the most recent
     `ase_task_save(id: '<ase-task-id/>', ...)` tool call -- this is
-    the rendering-prepared plan content and *MUST NOT* be confused
-    with the `text` *argument* passed into that call -- *without*
+    the *authoring form* of the plan and *MUST NOT* be confused
+    with the `text` *output* field of that call -- *without*
     calling `ase_task_load` again. Set <status>plan
     reused</status>. Do not output anything.
 </if>
 <else>
     Call the `ase_task_load(id: "<ase-task-id/>")` tool of the
-    `ase` MCP server to load the current task plan content and
-    set <text/> to the `text` output field of this `ase_task_load`
-    tool call. Do not output anything related to this MCP tool
-    call. Set <status>plan loaded</status>.
+    `ase` MCP server to load the current task plan content in its
+    *authoring form* -- the `variant` argument defaults to `source`
+    -- and set <text/> to the `text` output field of this
+    `ase_task_load` tool call. Do not output anything related to
+    this MCP tool call. Set <status>plan loaded</status>.
 </else>
 
 -   If <text/> starts with `ERROR:` or `WARNING:`:
     Set <task-content></task-content> (set task content to empty).
     Set <words/> to "0".
 
--   If <text/> starts NOT with `ERROR:` and NOT with `WARNING:`:
+-   If <text/> does NOT start with `ERROR:` and NOT with `WARNING:`:
     Set <task-content><text/></task-content> (set task content to text).
     Calculate the number of words <words/> of <task-content/>.
 
@@ -101,7 +102,7 @@ Only output the following <template/>:
 Update <timestamp-modified/> with the current time in ISO-style
 format, which has to be determined by calling the
 `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the `ase`
-MCP server and use the `text` field of its response. If
+MCP server and using the `text` field of its response. If
 <timestamp-created/> is still unset (because the plan content
 had no `Created:` frontmatter key), set
 <timestamp-created><timestamp-modified/></timestamp-created>
@@ -113,8 +114,8 @@ the number of words <words/> of <task-content/>.
 
 Call the `ase_task_save(id: "<ase-task-id/>", text:
 "<task-content/>")` tool of the `ase` MCP server to save the task
-plan content. Do not output anything related to this MCP call
-except the following <template/>:
+plan content in its *authoring form*. Do not output anything
+related to this MCP call except the following <template/>:
 
 <template>
 ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **<arg1/>**
@@ -143,7 +144,7 @@ except the following <template/>:
         ⧉ **ASE**: ☻ skill: **<arg1/>**, ▶ ERROR: invalid `--next` token: **<head/>**
         </template>
 
--   If <getopt-option-next/> is equal to `none`:
+-   Else, i.e. <getopt-option-next/> was *originally* equal to `none`:
 
     In the following, you *MUST* *NOT* use your built-in
     <user-dialog-tool/> tool! Instead, you *MUST* just show a
@@ -155,3 +156,20 @@ except the following <template/>:
     </expand>
 
 </define>
+
+<define name="task-next-handoff">
+
+Set <args>--int-reuse-task</args>.
+<if condition="<getopt-option-next/> is not equal `none`">
+    Set <args><args/> --next <getopt-option-next/></args>
+</if>
+Only output the following <template/> and then call the tool
+`Skill(skill: "ase:<arg1/>", args: "<args/>")` to invoke the
+`ase:<arg1/>` skill to continue with the updated plan. Immediately
+stop processing the current skill once the `Skill` tool was used.
+
+<template>
+⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **<arg2/>**
+</template>
+
+</define>

package/plugin/meta/ase-constitution.md

@@ -13,7 +13,7 @@ which boosts you to an expert-level Software Engineering AI agent.
 - Do *not* use braces around single-statement blocks in "if" and "while" constructs unless the language requires them.
 - 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* produce any trailing whitespace on any lines.
 - Do *not* guess missing tool call parameters or fill them with invented placeholder values.
 
 ## Commandments
@@ -24,7 +24,7 @@ which boosts you to an expert-level Software Engineering AI agent.
 - 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.
+- Before proposing any code changes, explain *WHAT* the proposed changes do and *WHY* they are necessary.
 - Use *concise* and *type-safe code* only.
 - Use *precise* and *surgical code changes* only.
 - Be very *pedantic* on code style.
@@ -36,7 +36,7 @@ which boosts you to an expert-level Software Engineering AI agent.
 - Always use *parentheses around arrow function parameters*, even for a single parameter.
 - Make a line break before the keywords "else", "catch", and "finally".
 - Try to *vertically align similar operators* on consecutive, similar lines.
-- Place spaces after opening and before closing angle brackets
+- Place spaces after opening and before closing square brackets
   (except for array access and array types) and braces (except for regular expression ranges).
 - 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.

package/plugin/meta/ase-control.md

@@ -6,9 +6,9 @@ Control Flow Constructs
     <define name="<define-name/>"><define-body/></define>:
 
     This specifies a *reusable definition* named <define-name/> and
-    an <define-body/> which can contain arbitrary information with
+    a <define-body/> which can contain arbitrary information with
     optional `<args/>` (or alternatively, individual `<arg1/>`,
-    `<arg2/>`, etc) and optional `<content/>` references from
+    `<arg2/>`, etc.) and optional `<content/>` references from
     subsequent <expand/> calls.
     This construct is expanded into nothing.
     Do not output anything.
@@ -20,7 +20,7 @@ Control Flow Constructs
     construct is expanded to the <define-body/> of <define/> with
     `<args/>` substituted with `<expand-arg1/> <expand-arg2/> [...]`,
     `<arg1/>` substituted with <expand-arg1/>, `<arg2/>` substituted
-    with <expand-arg2/>, etc, and `<content/>` substituted with
+    with <expand-arg2/>, etc., and `<content/>` substituted with
     <expand-content/>. Do not output anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
@@ -47,7 +47,7 @@ Control Flow Constructs
     <if condition="<if-condition/>"><if-body/></if>:
 
     This specifies a simple condition which is expanded to <if-body/>
-    if <if-condition/> is met, or to empty string if <if-condition/> is
+    if <if-condition/> is met, or to the empty string if <if-condition/> is
     *not* met. It can be optionally followed by one or more <elseif/>
     constructs and/or one final <else/> construct. Do not output anything else.
 
@@ -112,11 +112,11 @@ Control Flow Constructs
     anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
-    <agent-consolidation [group=<agent-group/>]/>
+    <agent-consolidation [group=<agent-group/>]/>:
 
     This specifies the merging of all the Git WorkTrees created by the
-    <agent/> calls with either are identified with the unique group
-    <agent-group/> or all <agent/> calls in the last <parallel/> section
+    <agent/> calls which either are identified with the unique group
+    <agent-group/> or occur in the last <parallel/> section
     of the context. After merging a single Git WorkTree, remove the Git
     WorkTree.
 

package/plugin/meta/ase-dialog.md

@@ -63,7 +63,7 @@ following procedure:
 
             <text>
             <text/>
-            <ase-tpl-boxline><label-key/>  ▶  <label-text/><label-pad/> <description/></ase-tpl-boxline>
+            <label-key/>  ▶  <label-text/><label-pad/> <description/>
             </text>
 
             <if condition="<keys/> is empty">
@@ -82,7 +82,7 @@ following procedure:
         </else>
 
         <if condition="<opts/> contains `--other` and does *not* contain `--no-other`">
-            Set <hint>Please choose *one* option by typing <keys/>, or other free-text instruction.</hint>.
+            Set <hint>Please choose *one* option by typing <keys/>, or any other free-text instruction.</hint>.
         </if>
         <else>
             Set <hint>Please choose *one* option by typing <keys/>.</hint>.
@@ -93,7 +93,7 @@ following procedure:
         <text>
         <ase-tpl-boxed title="DIALOG" subtitle="<question-label/>">
 
-        <ase-tpl-boxline>**<question-description/>**</ase-tpl-boxline>
+        **<question-description/>**
 
         <text/>
 
@@ -125,7 +125,8 @@ following procedure:
             otherwise indicates that the user doesn't want to proceed,
             or the user declined to answer the question, or that
             the dialog was cancelled, rejected or skipped, set
-            <result>CANCEL</result>.
+            <result>CANCEL</result> and *SKIP* all remaining steps
+            2.3.3 - 2.3.4 of this dispatch.
 
         3.  Otherwise, determine the selected <label/>
             by mapping the <result/> (usually containing one of the

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

@@ -18,20 +18,6 @@ at `01`) according to the order of the **Artifact** list below, and with
 Pascal-casing each word (upper-casing its first letter) and using `-`
 characters instead of spaces (e.g. `Context-View`).
 
-Each **Artifact** file *MUST* begin with a single blank line before its
-`#` heading and end with a single blank line after its last content line
-(followed by the trailing newline), mirroring the blank lines shown
-inside the `<format>` blocks below.
-
-Each **Artifact** contains two timestamps: the <timestamp-created/>
-is the timestamp when this **Artifact** was created. The
-<timestamp-modified/> is the timestamp when this **Artifact** was last
-modified. Both use an ISO-style format value. The value of both can be
-determined by a call to the `ase_timestamp(format: "yyyy-LL-dd HH:mm")`
-tool of the `ase` MCP server and use the `text` field of its response.
-Whenever an **Artifact** is updated, the <timestamp-modified/> *MUST* be
-updated, too.
-
 The **Artifact Set** **Architecture (ARCH)** consists of the following
 distinct **Artifact**s (listed under their <artifact-name/> and their
 <artifact-id/>):
@@ -84,7 +70,6 @@ distinct **Artifact**s (listed under their <artifact-name/> and their
 The **Artifact**s have the following cross-references:
 
 ```text
-ARCH-02-FV Functionality View   ──(depends on)─► ARCH-01-CV Context View
 ARCH-03-IV Information View     ──(entity)─►     SPEC-07-DM Data Model
 ARCH-03-IV Information View     ──(owner)─►      ARCH-02-FV Functionality View
 ARCH-04-CO Concurrency View     ──(hosts)─►      ARCH-02-FV Functionality View
@@ -831,7 +816,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
 
     -   <arch-dr-decision-notes/> is *OPTIONAL* and can be omitted when it
         does not add genuine value - most decisions won't need it. The
-        following usually goes into it: information of the decision *process*
+        following usually goes into it: information about the decision *process*
         (e.g. a weighted decision matrix of considered alternatives);
         consequences of the decision (but only when non-obvious downstream
         effects need to be called out); and links to strongly related
@@ -850,7 +835,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
         almost inevitable answer to the context - if a reader is surprised
         by the decision, either the context is missing a force, or the
         decision is under-justified. The rationale should make the decision
-        feel earned, not asserted - if you would delete the rationale and
+        feel earned, not asserted - if you delete the rationale and
         the decision suddenly looks arbitrary, the rationale was doing its
         job.
 
@@ -892,7 +877,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
 
     -   **Boundary and scope decisions.** "Customer data is owned by the
         Customer context; other contexts reference it by ID only." The explicit
-        no-s are as valuable as the yes-s.
+        no's are as valuable as the yes's.
 
     -   **Deliberate deviations from the obvious path.** "We're using
         manual SQL instead of an ORM because X." Anything where a reasonable
@@ -1091,7 +1076,7 @@ its purpose, and the alternatives that were considered but not chosen.
         to bootstrap application parameters.
 
     -   **Configuration Parsing**:
-        Load and parse directives from configuration file to bootstrap
+        Load and parse directives from a configuration file to bootstrap
         application parameters.
 
     -   **Process Daemonizing**:
@@ -1103,7 +1088,7 @@ its purpose, and the alternatives that were considered but not chosen.
         and control them during the life-cycle of the application.
 
     -   **Component Management**:
-        Structure the code into components, instantiate them under run-time
+        Structure the code into components, instantiate them at run-time
         and manage them in a stateful component life-cycle.
 
     -   **Component Communication**:
@@ -1151,7 +1136,7 @@ its purpose, and the alternatives that were considered but not chosen.
         measurement information at certain points of interest.
 
     -   **Database Access**:
-        Map in-memory domain entities onto data store dependent persistent
+        Map in-memory domain entities onto a data-store-dependent persistent
         data structure.
 
     -   **Database Connectivity**:

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

@@ -51,8 +51,7 @@ Artifact Meta Information
     name (for stable ordering) and is *not* part of the **Artifact**'s
     or its **Aspect**s' identifiers.
 
-    Each **Artifact** *MUST* have an initial blank line and a trailing
-    blank line. All its lines should be kept below 140 characters,
+    All lines of an **Artifact** should be kept below 140 characters,
     whenever possible by line-breaking with newlines after about 120
     characters per line.
 
@@ -64,6 +63,20 @@ Artifact Meta Information
     characters and in total not longer than 30 characters). An example
     is `user-login`.
 
+Each **Artifact** file *MUST* begin with a single blank line before its
+`#` heading and end with a single blank line after its last content line
+(followed by the trailing newline), mirroring the blank lines shown
+inside the `<format>` blocks below.
+
+Each **Artifact** contains two timestamps: the <timestamp-created/>
+is the timestamp when this **Artifact** was created. The
+<timestamp-modified/> is the timestamp when this **Artifact** was last
+modified. Both use an ISO-style format value. The value of both can be
+determined by a call to the `ase_timestamp(format: "yyyy-LL-dd HH:mm")`
+tool of the `ase` MCP server, using the `text` field of its response.
+Whenever an **Artifact** is updated, the <timestamp-modified/> *MUST* be
+updated, too.
+
 An **Artifact** *MAY* additionally declare an **Export** -- a derived,
 ready-to-consume rendering of (part of) its content, materialized as a
 *side-by-side* file next to the **Artifact** itself. An **Artifact**

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

@@ -18,20 +18,6 @@ at `01`) according to the order of the **Artifact** list below, and with
 Pascal-casing each word (upper-casing its first letter) and using `-`
 characters instead of spaces (e.g. `Customer-Journey`).
 
-Each **Artifact** file *MUST* begin with a single blank line before its
-`#` heading and end with a single blank line after its last content line
-(followed by the trailing newline), mirroring the blank lines shown
-inside the `<format>` blocks below.
-
-Each **Artifact** contains two timestamps: the <timestamp-created/>
-is the timestamp when this **Artifact** was created. The
-<timestamp-modified/> is the timestamp when this **Artifact** was last
-modified. Both use an ISO-style format value. The value of both can be
-determined by a call to the `ase_timestamp(format: "yyyy-LL-dd HH:mm")`
-tool of the `ase` MCP server and use the `text` field of its response.
-Whenever an **Artifact** is updated, the <timestamp-modified/> *MUST* be
-updated, too.
-
 The **Artifact Set** **Specification (SPEC)** consists of the following
 distinct **Artifact**s (listed under their <artifact-name/> and their
 <artifact-id/>):
@@ -122,7 +108,6 @@ SPEC-06-BR Business Rules    ──(constrains)─►     SPEC-05-NR Non-Functio
 SPEC-08-SM State Model       ──(of entity)─►      SPEC-07-DM Data Model
 SPEC-10-UC Use Cases         ──(use case actor)─► SPEC-02-PE Personas
 SPEC-10-UC Use Cases         ──(realizes)─►       SPEC-04-FR Functional Requirements
-SPEC-10-UC Use Cases         ──(transitions)─►    SPEC-08-SM State Model
 SPEC-11-TC Test Cases        ──(verifies)─►       SPEC-04-FR Functional Requirements
 SPEC-11-TC Test Cases        ──(verifies)─►       SPEC-05-NR Non-Functional Requirements
 SPEC-15-DS Dialog Storyboard ──(scenario)─►       SPEC-10-UC Use Cases
@@ -221,7 +206,7 @@ capturing their goals, needs, behaviors, and context.
         in total not longer than 30 characters), derived from
         <spec-pe-persona-name/>.
 
-    -   <spec-pe-persona-name/>: per-artifact unique first name of fictional
+    -   <spec-pe-persona-name/>: per-artifact unique first name of the fictional
         described person.
 
     -   <spec-pe-persona-gender/>: the gender of the persona: `male`,
@@ -231,7 +216,7 @@ capturing their goals, needs, behaviors, and context.
 
     -   <spec-pe-persona-role/>: the role of the persona.
 
-    -   <spec-pe-persona-quote/>: a short and bold, first-person statement -
+    -   <spec-pe-persona-quote/>: a short and bold first-person statement -
         written in the persona's own voice - that captures their core
         attitude, motivation, frustration, or need in a single memorable line.
         It's sometimes called the persona's "tagline," "mantra," or "defining
@@ -287,12 +272,12 @@ over time.
 
     -   <spec-cj-step-stage/> is one of:
 
-        -   `Awareness`:     Customer is not aware of solution, but has a need.
-        -   `Consideration`: Customer is aware of solution, and should consider its use.
+        -   `Awareness`:     Customer is not aware of the solution, but has a need.
+        -   `Consideration`: Customer is aware of the solution, and should consider its use.
         -   `Decision`:      Customer wants to pick the solution.
         -   `Onboarding`:    Customer is using the solution.
-        -   `Retention`:     Customer in the long-term stays a customer.
-        -   `Advocacy`:      Customer is a fan of solution and tells the tribe.
+        -   `Retention`:     Customer in the long term stays a customer.
+        -   `Advocacy`:      Customer is a fan of the solution and tells the tribe.
 
     -   <spec-cj-step-actor/> is a `SPEC-PE-<spec-pe-persona-id/>` reference to the
         corresponding **Aspect** of the Personas **Artifact**.
@@ -564,7 +549,7 @@ manages, defining how information is organized and connected.
 
     ### RELATIONS
 
-    -   `<spec-dm-relation-id/>`: [`<spec-dm-relation-target/>`](#<spec-dm-relation-target-id/>)(`<spec-dm-relation-cardinality/>`):<br/>
+    -   `<spec-dm-relation-id/>`: [`<spec-dm-relation-target/>`](#SPEC-DM-<spec-dm-relation-target-id/>)(`<spec-dm-relation-cardinality/>`):<br/>
         <spec-dm-relation-description/>,
         **BECAUSE** <spec-dm-relation-rationale/>.
 
@@ -664,12 +649,12 @@ manages, defining how information is organized and connected.
         -   `Type`          (`<spec-dm-attribute-qualifier/><spec-dm-attribute-type/>`)
         -   `Description`   (`<spec-dm-attribute-description/>, **BECAUSE** <spec-dm-attribute-rationale/>.`)
 
-    -   <export-table-2/> is a Markdown table for the relation with one
+    -   <export-table-2/> is a Markdown table for the relations with one
         row per <spec-dm-relation-id/>, sorted by <spec-dm-relation-id/> --
         with the columns:
 
         -   `Relation`      (`**<spec-dm-relation-id/>**`)
-        -   `Target`        (`[<spec-dm-relation-target/>](#<spec-dm-relation-target-id/>) (<spec-dm-relation-cardinality/>)`)
+        -   `Target`        (`[<spec-dm-relation-target/>](#SPEC-DM-<spec-dm-relation-target-id/>) (<spec-dm-relation-cardinality/>)`)
         -   `Description`   (`<spec-dm-relation-description/>, **BECAUSE** <spec-dm-relation-rationale/>.`)
 
     -   In case a <spec-dm-entity/> has no relations at all, the

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

@@ -139,14 +139,14 @@ You *MUST* honor the following hints on this *task* format:
     task plan was last modified. Both use an ISO-style format
     value. The value of both can be determined by a call to the
     `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the `ase` MCP
-    server and use the `text` field of its response.
+    server, using the `text` field of its response.
 
 -   The <title/> is a short summary of the <summary-what/>, no longer than
     50 characters.
 
 -   The sections `##  CHANGES` and `##  VERIFICATION` are each just a short
     list of 1-5 bullet points. Each bullet point is formatted as
-    `- **<aspect/>**: <specification/>` where <aspect/> indicates
+    `-   **<aspect/>**: <specification/>` where <aspect/> indicates
     the aspect of the section and <specification/> is 1-3 sentences
     giving an *ultra precise* but also *ultra brief* and *ultra concise*
     description of the aspect.

package/plugin/meta/ase-getopt.md

@@ -36,7 +36,7 @@ set placeholders into the context as a side-effect.
         Additionally, simulate <getopt-info/> as a comma-separated
         markdown rendering of the parsed options in the form `<longN/>:
         **<valueN/>**, [...]` (joined with `, `, with each value
-        shell-quoted if value contains spaces or special characters, and
+        shell-quoted if the value contains spaces or special characters, and
         excluding the `help` option and any *internal* option whose long
         name starts with `int-`).
 

package/plugin/meta/ase-persona.md

@@ -61,7 +61,7 @@ requested communication style at any time during a session.
         -   <keywords/> is only one to four keywords summarizing the <details/>
         -   <details/> is one to four concise prose sentences explaining the aspect
 
--   If <ase-persona-style/> is `telegrapher`, or `caveman`:
+-   If <ase-persona-style/> is `telegrapher` or `caveman`:
     -   You *MUST* *use only* bullet point lists without blank lines between bullet points.
     -   You *MUST* *use only* one bullet point per explanation aspect.
     -   You *MUST* *use* shorter synonyms
@@ -89,13 +89,13 @@ requested communication style at any time during a session.
             -   `<subject/> ▶ <action/> ▷ <object/>.`
             -   `<subject/> ▶ <action/>.`
             Each of <subject/>, <action/>, <object/>, and <reason/>
-            are just one to six words.
+            is just one to six words.
 
 -   If <ase-persona-style/> is `caveman`:
     -   You *MUST* structure every bullet point by
         following exactly the formatting `○ <core/>`, where:
         <core/> is a *very terse core* stating the essence of the aspect
-        using one of the following three sentence patterns:
+        using one of the following four sentence patterns:
         -   `<expression/>!`
         -   `<subject/> <action/> <object/>, <reason/>.`
         -   `<subject/> <action/> <object/>.`