@rse/ase 0.0.40 → 0.0.42

package/plugin/skills/ase-arch-discover/SKILL.md

@@ -9,14 +9,11 @@ disable-model-invocation: false
 effort: medium
 allowed-tools:
     - "Bash(npm search --json *)"
-    - "Bash(npm view --json *)"
     - "Skill"
     - "Agent"
-    - "WebFetch"
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 
 Discover Components
@@ -113,26 +110,6 @@ for the technology stack to *provide* the *needed functionality*
             (L=1-M). Merge the results into the already existing result
             set, but deduplicate entries.
 
-        -   For each discovered *NPM package* <component-K/> (K=1-N),
-            use the shell command `npm view --json "<package-K/>"
-            version time repository.url` to discover
-            its version <version-K/>, the publish time of that
-            version <updated-K/> (read from `time[<version-K/>]`),
-            its time created <created-K/> (read from `time.created`),
-            and its repository URL <repository-K/>.
-
-        -   If the <repository-K/> regexp-matches
-            `.+?//github\.com/([^/]+/[^/.]+).*` use the `WebFetch` tool
-            to fetch the URL `https://api.github.com/repos/$1` (`$1`
-            is the value matched by the first capturing parenthesis
-            in the regexp) and extract <stars-K/> from its JSON
-            `stargazers_count` field, else set <stars-K/> to `N.A.`.
-
-        -   For each discovered *NPM package* <component-K/>
-            (K=1-N), use the `WebFetch` tool on the URL
-            `https://api.npmjs.org/downloads/point/last-month/<package-K/>`
-            to extract the <downloads-K/> from the `downloads` field.
-
     -   If <stack/> is "Java" or "Kotlin":
 
         -   Based on the essential keywords <keyword-L/> (L=1-M),
@@ -140,25 +117,60 @@ for the technology stack to *provide* the *needed functionality*
             discover an initial set of a maximum of 12 *Java packages*
             <component-K/> and at least their real name <name-K/> and
             their unique package names <package-K/>.
+
+    -   Call the `component_info(stack: <stack/>, components:
+        [ <package-1/>, ..., <package-N/> ])` tool of the `ase` MCP
+        service *once* for the entire set of discovered packages.
+        The tool dispatches internally on <stack/> and fetches all
+        metadata in maximum parallel and returns an array of objects `{
+        name, version, time, repository, stars, downloads }`. For each
+        component <component-K/> (K=1-N) read from its corresponding
+        entry: <version-K/> from `version`, <updated-K/> from `updated`,
+        <created-K/> from `created`, <repository-K/> from `repository`,
+        <stars-K/> from `stars` (numeric or `N.A.`), <downloads-K/>
+        from `downloads` (numeric or `N.A.`) and <rank-K/> from `rank`
+        (numeric).
+
+    -   Sort, in descending order, the discovered components
+        <component-K/> (K=1-N) by their `rank` field and trim the result
+        list to just a maximum of 12 total components.
+
+    -   For each component <component-K/> (K=1-N), research and then
+        decide which *one* of *USP* (Unique Selling Point -- what makes
+        it unique), *Crux* (what you should notice), or *Gotcha* (what
+        you should not stumble over) is its single most distinguishing
+        perspective, and remember this as an <info-K/> (K=1-N) formatted
+        like `<type/>: <hint/>` where <type/> is one of `USP`, `Crux`,
+        or `Gotcha` and <hint/> is a 1-6 word hint. Do not output
+        anything.
     </step>
 
 4.  <step id="STEP 4: Report Components">
-    -   Sort, in descending order, the discovered components
-        <component-K/> (K=1-N) first by their <downloads-K/> and second
-        by their <stars-K/> and trim the result list to just a maximum
-        of 12 total components.
+    -   Display the determined, individual components as a Markdown
+        *table* with just the following <template/> and do not output
+        anything else:
+
+        <template>
+        &#x1F535; **COMPONENT HINTS**:
+
+        | ⚑ *Component*      | ▣ *Package*    | ⚖ *Hint*  |
+        | :----------------- | :------------- | :-------- |
+        | **<component-1/>** | `<package-1/>` | <info-1/> |
+        [...]
+        | **<component-N/>** | `<package-N/>` | <info-N/> |
+        </template>
 
     -   Display the discovered components as a Markdown *table*
         with just the following <template/>:
 
         <template>
-        &#x1F535; **COMPONENTS**:
+        &#x1F535; **COMPONENT RANKING**:
 
-        | *Component*   | *Package*      | *Version*    | *Downloads*        | *Stars*        | *Updated*        | *Created*    |
-        | :------------ | :------------- | -----------: | -----------------: | -------------: | :--------------- | :----------- |
-        | **<name-1/>** | `<package-1/>` | <version-1/> | **<downloads-1/>** | **<stars-1/>** | **<updated-1/>** | <created-1/> |
+        | ⚑ *Component*      | ▣ *Package*    | ❖ *Version*  | ↓ *Downloads*      | ⎈ *Stars*      | ⏲ *Updated*      | ☆ *Created*  |
+        | :----------------- | :------------- | -----------: | -----------------: | -------------: | :--------------- | :----------- |
+        | **<component-1/>** | `<package-1/>` | <version-1/> | **<downloads-1/>** | **<stars-1/>** | **<updated-1/>** | <created-1/> |
         [...]
-        | **<name-N/>** | `<package-N/>` | <version-N/> | **<downloads-N/>** | **<stars-N/>** | **<updated-N/>** | <created-N/> |
+        | **<component-N/>** | `<package-N/>` | <version-N/> | **<downloads-N/>** | **<stars-N/>** | **<updated-N/>** | <created-N/> |
         </template>
     </step>
 </flow>

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

@@ -11,7 +11,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 
 Analyze Source Code
@@ -34,78 +33,77 @@ code, for problems in its *logic* and *semantics* and its related
 
 <flow>
 
-1. <step id="STEP 1: Investigate Code Base">
-   In this STEP 1, investigate on the code. If the code base is large,
-   you *MUST* use the `Agent` tool (not inline work) to create multiple
-   sub-agents to split the investigation task into appropriate chunks.
-   Hints:
+1.  <step id="STEP 1: Investigate Code Base">
+    In this STEP 1, investigate on the code. If the code base is large,
+    you *MUST* use the `Agent` tool (not inline work) to create multiple
+    sub-agents to split the investigation task into appropriate chunks.
 
-   - During investigation in this STEP 1, do *not* output anything else,
-     especially do not give any further explanations or information.
+    Tenets:
 
-   - Focus on *practically relevant* cases and especially do *not*
-     investigate on theoretical or fictive cases.
+    -   **Quiet Operation**:
+        During investigation in this STEP 1, do *not* output anything else,
+        especially do not give any further explanations or information.
 
-   - In case of problems related to *obvious or expected* errors,
-     they *should* be handled *near the origin*.
+    -   **Practical Relevance Only**:
+        Focus on *practically relevant* cases and especially do *not*
+        investigate on theoretical or fictive cases.
 
-   - In case of problems related to *theoretical or unexpected* errors,
-     they *should* be handled in parent scopes to avoid cluttering the
-     source code with too much error handling at all.
+    -   **Problem Focus Only**:
+        Still focus on the *problem only* and do *not* already
+        investigate on any possible *solution*.
+    </step>
 
-   - In this STEP 1, still focus on the *problem only* and do *not*
-     investigate on any possible *solution*.
-   </step>
+2.  <step id="STEP 2: Show Results">
+    In this STEP 2, for every detected problem, immediately report it
+    with the following output <template/>, based on concise bullet
+    points.
 
-2. <step id="STEP 2: Show Results">
-   In this STEP 2, for every detected problem, immediately report it
-   with the following output <template/>, based on concise bullet
-   points.
+    <template>
+    &#x1F7E0; PROBLEM (Severity: **<severity/>**): **P<n/>**: **<title/>**
 
-   <template>
-   &#x1F7E0; PROBLEM (Severity: **<severity/>**): **P<n/>**: **<title/>**
+    <description/>
+    </template>
 
-   <description/>
-   </template>
+    Hints:
 
-   Hints:
-   - For the final results, do *not* output anything else, especially do
-     *not* give any further explanations or information.
+    -   For the final results, do *not* output anything else, especially do
+        *not* give any further explanations or information.
 
-   - Uniquely identify the problems with `P<n/>` where <n/> is 1, 2, ...
+    -   Uniquely identify the problems with `P<n/>` where <n/> is 1, 2, ...
 
-   - In <description/>, use *very brief* but as *precise* as possible problem
-     descriptions.
+    -   In <description/>, use *ultra brief* but still as *precise* as
+        possible problem descriptions.
 
-   - In <description/>, highlight *code* as <template>`<code/>`</template>
-     and *key aspects* as <template>*<aspect/>*</template>.
+    -   In <description/>, highlight *code* as <template>`<code/>`</template>
+        and *key aspects* as <template>*<aspect/>*</template>.
 
-   - In <description/>, add inline *references* to the related
-     code positions in the form of either
-     <template>(`<filename/>:<line-number/>`)</template>,
-     <template>(`<filename/>:<line-number/>-<line-number/>`)</template> or
-     <template>(`<filename/>#<function-or-method/>`)</template>.
+    -   In <description/>, add inline *references* to the related
+        code positions in the form of either
+        <template>(`<filename/>:<line-number/>`)</template>,
+        <template>(`<filename/>:<line-number/>-<line-number/>`)</template> or
+        <template>(`<filename/>#<function-or-method/>`)</template>.
 
-   - In <description/>, classify the problem with a <severity/>
-     of <template>LOW</template>, <template>MEDIUM</template> or
-     <template>HIGH</template>.
+    -   In <description/>, classify the problem with a <severity/>
+        of <template>LOW</template>, <template>MEDIUM</template> or
+        <template>HIGH</template>.
 
-   - *Additionally*, first call the `kv_clear()` tool of the `ase`
-     MCP service to clear the in-memory key/value store, and then, for
-     *every* reported problem, persist its problem analysis result
-     via the `kv_set` tool of the `ase` MCP service, using `key` set
-     to `ase-issue-P<n/>` and `val` set to `<title/>: <description/>`.
-   </step>
+    -   *Additionally*, persist all reported problems in a *single*
+        `kv_batch` call to the `ase` MCP service with `transactional`
+        set to `true`. The `commands` parameter array of this call
+        starts with one `{ command: "clear" }` entry, followed by one
+        `{ command: "set", key: "ase-issue-P<n/>", val: "<title/>:
+        <description/>" }` entry per reported problem.
+    </step>
 
-3. <step id="STEP 3: Give Final Hint">
-   Finally, in this STEP 3, output the following <template/> to give a
-   final hint:
+3.  <step id="STEP 3: Give Final Hint">
+    Finally, in this STEP 3, output the following <template/> to give a
+    final hint:
 
-   <template>
-   ⧉ **ASE**: ☻ skill: **<skill-name/>**, ▶ status: **skill finished**
-   ⧉ **ASE**: ↪ hint: **For deeper analysis, suggestions on solution approaches and then final problem resolution, use `/ase-code-resolve P{n}` in the same or even a different session.**
-   </template>
-   </step>
+    <template>
+    ⧉ **ASE**: ☻ skill: **<skill-name/>**, ▶ status: **skill finished**
+    ⧉ **ASE**: ↪ hint: **For deeper analysis, suggestions on solution approaches and then final problem resolution, use `/ase-code-resolve P{n}` in the same or even a different session.**
+    </template>
+    </step>
 
 </flow>
 

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

@@ -12,7 +12,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
@@ -122,32 +121,58 @@ permitted way to persist artifacts is via `task_save(...)`.
 
 3.  **Internalize Crafting Tenets**:
 
-    Internalize and honor the following tenets.
+    You *MUST* internalize and honor the following tenets when crafting the new feature.
     Do not output anything.
 
-    1.  *Recommended* Tenets (generic):
+    1.  Generic Tenets:
+
+        -   **Separation of Concerns**:
+            Clearly separate all individual concerns as good as possible.
+
+        -   **Code Base Alignment**:
+            Strictly align with the existing source code base by exactly
+            following its coding style, its structure, its naming
+            conventions, etc.
+
+    2.  Specific Tenets:
 
         -   **Surgical Changes**:
             Keep source code changes always as small as possible.
 
-        -   **Separation of Concerns**:
-            Clearly separate all individual concerns as good as possible.
+        -   **Clear Minimal Scope**:
+            Establish explicit boundaries for the new feature.
+            Avoid feature scope creep and over-engineering.
+
+        -   **Keep it Simple, Stupid (KISS)**:
+            Build with the simplest design that solves the real problem.
+            Avoid over-engineering.
+
+        -   **You Aren't Gonna Need It (YAGNI)**:
+            Build for today's actual needs, not speculative futures.
+            Avoid premature optimizations, premature abstractions,
+            over-configurability, etc.
 
-        -   **Single Responsibility Principle**:
-            Every module, class, or function should have only one reason to change.
+        -   **Don't Repeat Yourself (DRY)**:
+            Avoid redundancies, but honor the *Rule of Three*: Don't
+            abstract on the first occurrence -- tolerate (small)
+            duplication on the second -- factor out on the third only.
 
-        -   **Behavior Preservation**:
-            Refactoring changes only re-structure, never change any observable behavior.
+        -   **Single Responsibility Principle (SRP)**:
+            Every module, class, or function should have only one reason
+            to change.
 
-        -   **Align with Code Base**:
-            Strictly align with the existing code base by exactly following its
-            coding style, its structure, its naming conventions, etc.
+        -   **Loose Coupling, High Cohesion**:
+            Strike for good modularity by a set of small, focused parts
+            (high cohesion), connected by thin, explicit wires and
+            interfaces (loose coupling).
 
-    2.  *Essential* Tenets (feature crafting specific):
+        -   **Clear Interfaces**:
+            Design clear interfaces, contracts, and data models --
+            with high attention to boundaries and modularity.
 
-        -   **High Cohesion, Low Coupling**:
-            Strike for a set of small, focused parts (high cohesion) connected by
-            thin, explicit wires (low coupling).
+        -   **Non-Functional Requirements**:
+            Honor the non-functional requirements Performance, Security,
+            Scalability, Comprehensibility.
 
 4.  **Find Feature Crafting Approaches**:
 
@@ -168,14 +193,20 @@ permitted way to persist artifacts is via `task_save(...)`.
         ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
         empty <annotation/>. Do *not* output anything in this sub-step.
 
-    4.  *Now* report each approach with the following <template/>,
+    4.  Indicate start of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(** `APPROACHES-BEGIN` **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </template>
+
+    5.  Now report each approach with the following <template/>,
         inlining its pros/cons derived in sub-step 2:
 
         <template>
-        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        ● [...]
-        ● [...]
-        ● [...]
+        ● **APPROACH A<n/>**<annotation/>: *<summary/>*
+        ○ [...]
+        ○ [...]
+        ○ [...]
         ⊕ *pro*: [...]
         ⊖ *con*: [...]
         <optional-diagram/>
@@ -200,6 +231,12 @@ permitted way to persist artifacts is via `task_save(...)`.
             `**After:**`); never side-by-side. Omit <optional-diagram/>
             entirely for simple or purely local situation.
 
+    6.  Indicate end of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(**  `APPROACHES-END`  **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </template>
+
 5.  **Choose Feature Crafting Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`:

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

@@ -13,7 +13,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 
 Explain Source Code

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

@@ -15,7 +15,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 
 Project Insight

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

@@ -9,7 +9,6 @@ effort: medium
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 
 Lint Source Code

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

@@ -12,7 +12,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
@@ -122,35 +121,47 @@ permitted way to persist artifacts is via `task_save(...)`.
 
 3.  **Internalize Refactoring Tenets**:
 
-    Internalize and honor the following tenets.
+    You *MUST* internalize and honor the following tenets when refactoring.
     Do not output anything.
 
-    1.  *Recommended* Tenets (generic):
-
-        -   **Surgical Changes**:
-            Keep source code changes always as small as possible.
+    1.  Generic Tenets:
 
         -   **Separation of Concerns**:
             Clearly separate all individual concerns as good as possible.
 
-        -   **Single Responsibility Principle**:
-            Every module, class, or function should have only one reason to change.
+        -   **Code Base Alignment**:
+            Strictly align with the existing source code base by exactly
+            following its coding style, its structure, its naming
+            conventions, etc.
+
+    2.  Specific Tenets:
 
         -   **Behavior Preservation**:
-            Refactoring changes only re-structure, never change any observable behavior.
+            Refactoring changes only re-structure, never change any
+            observable behavior at all. Especially, do not mix with
+            problem resolving and feature crafting.
 
-        -   **Align with Code Base**:
-            Strictly align with the existing code base by exactly following its
-            coding style, its structure, its naming conventions, etc.
+        -   **Boy Scout Rule**:
+            After the refactoring, leave the source code base cleaner
+            than you found it.
 
-    2.  *Essential* Tenets (refactoring specific):
+        -   **Don't Repeat Yourself (DRY)**:
+            Avoid redundancies, but honor the *Rule of Three*: Don't
+            abstract on the first occurrence -- tolerate (small)
+            duplication on the second -- factor out on the third only.
 
-        -   **Boy Scout Rule**:
-            After the refactoring, leave the code base cleaner than you found it.
+        -   **Single Responsibility Principle (SRP)**:
+            Every module, class, or function should have only one reason
+            to change.
 
-        -   **High Cohesion, Low Coupling**:
-            Strike for a set of small, focused parts (high cohesion) connected by
-            thin, explicit wires (low coupling).
+        -   **Loose Coupling, High Cohesion**:
+            Strike for good modularity by a set of small, focused parts
+            (high cohesion), connected by thin, explicit wires and
+            interfaces (loose coupling).
+
+        -   **Clear Interfaces**:
+            Design clear interfaces, contracts, and data models --
+            with high attention to boundaries and modularity.
 
 4.  **Find Refactoring Approaches**:
 
@@ -171,15 +182,21 @@ permitted way to persist artifacts is via `task_save(...)`.
         ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
         empty <annotation/>. Do *not* output anything in this sub-step.
 
-    4.  *Now* report each approach with the following <template/>,
+    4.  Indicate start of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(** `APPROACHES-BEGIN` **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </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>
-        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        ● [...]
-        ● [...]
-        ● [...]
+        ● **APPROACH A<n/>**<annotation/>: *<summary/>*
+        ○ [...]
+        ○ [...]
+        ○ [...]
         ⊕ *pro*: [...]
         ⊖ *con*: [...]
         <optional-diagram/>
@@ -204,6 +221,12 @@ permitted way to persist artifacts is via `task_save(...)`.
             `**After:**`); never side-by-side. Omit <optional-diagram/>
             entirely for simple or purely local situation.
 
+    6.  Indicate end of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(**  `APPROACHES-END`  **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </template>
+
 5.  **Choose Refactoring Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`:

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

@@ -12,7 +12,6 @@ allowed-tools:
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
@@ -170,33 +169,45 @@ permitted way to persist artifacts is via `task_save(...)`.
 
 3.  **Internalize Problem Resolution Tenets**:
 
-    Internalize and honor the following tenets.
+    You *MUST* internalize and honor the following tenets when resolving the problem.
     Do not output anything.
 
-    1.  *Recommended* Tenets (generic):
-
-        -   **Surgical Changes**:
-            Keep source code changes always as small as possible.
+    1.  Generic Tenets:
 
         -   **Separation of Concerns**:
             Clearly separate all individual concerns as good as possible.
 
-        -   **Single Responsibility Principle**:
-            Every module, class, or function should have only one reason to change.
+        -   **Code Base Alignment**:
+            Strictly align with the existing source code base by exactly
+            following its coding style, its structure, its naming
+            conventions, etc.
 
-        -   **Behavior Preservation**:
-            Refactoring changes only re-structure, never change any observable behavior.
+    2.  Specific Tenets:
 
-        -   **Align with Code Base**:
-            Strictly align with the existing code base by exactly following its
-            coding style, its structure, its naming conventions, etc.
-
-    2.  *Essential* Tenets (problem resolving specific):
+        -   **Surgical Changes**:
+            Keep source code changes always as small as possible.
 
         -   **No Cleanups**:
-            Strictly focus on resolving the problem and do not mix this task
-            with any other necessary code cleanups, except they are really
-            necessary for resolving the task.
+            Strictly focus on resolving the problem and do not mix this
+            task with any other necessary code cleanups, except they are
+            really necessary for resolving the task.
+
+        -   **Minimum Flags**:
+            Use the absolute minimum total number of flags (boolean
+            variables) to span the entire space of scenarios. Prefer the
+            adjustment of existing flags over the introduction of new
+            flags.
+
+        -   **Code Adequacy**:
+            As little increase in overall source code complexity as
+            possible, as much new problem resolution source code as
+            necessary.
+
+        -   **Origin Proximity**:
+            Problems for *obvious, particular, or expected* errors
+            *should* be handled *near the origin*. Problems for
+            *theoretical, fictive, or unexpected* errors, *should* be
+            handled more general and in parent scopes.
 
 4.  **Find Problem Resolution Approaches**:
 
@@ -217,15 +228,21 @@ permitted way to persist artifacts is via `task_save(...)`.
         ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
         empty <annotation/>. Do *not* output anything in this sub-step.
 
-    4.  *Now* report each approach with the following <template/>,
+    4.  Indicate start of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(** `APPROACHES-BEGIN` **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </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>
-        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        ● [...]
-        ● [...]
-        ● [...]
+        ● **APPROACH A<n/>**<annotation/>: *<summary/>*
+        ○ [...]
+        ○ [...]
+        ○ [...]
         ⊕ *pro*: [...]
         ⊖ *con*: [...]
         <optional-diagram/>
@@ -237,17 +254,6 @@ permitted way to persist artifacts is via `task_save(...)`.
             *precise* and *brief* resolution information. Try to keep the
             number of bullet points (●) in the range of 1-4.
 
-        -   Focus on resolution approaches for *practically relevant* cases and do *not*
-            investigate on theoretical or fictive cases. This is especially the case
-            for error handling cases and race condition cases.
-
-        -   In case of resolution approaches for problems related to *obvious or
-            expected* errors, they *should* be handled *near the origin*.
-
-        -   In case of resolution approaches for problems related to *theoretical
-            or unexpected* errors, they *should* be handled in parent scopes to
-            avoid cluttering the source code with too much error handling at all.
-
         -   In case of a *complex resolution situation* only,
             visualize it with an optional diagram <optional-diagram/>
             by building a Mermaid specification <mermaid-spec/>
@@ -261,6 +267,12 @@ permitted way to persist artifacts is via `task_save(...)`.
             `**After:**`); never side-by-side. Omit <optional-diagram/>
             entirely for simple or purely local situation.
 
+    6.  Indicate end of reporting by showing the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ┈┈┈┈┈┈┈┈────────━━━━━━━━**(**  `APPROACHES-END`  **)**━━━━━━━━────────┈┈┈┈┈┈┈┈
+        </template>
+
 5.  **Choose Problem Resolution Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`: