@rse/ase 0.0.41 → 0.0.42

package/dst/ase-kv.js

@@ -17,6 +17,11 @@ export class KV {
     static validateKey(key) {
         if (typeof key !== "string" || key.length === 0)
             throw new Error("kv: key must be a non-empty string");
+        if (key.trim().length === 0)
+            throw new Error("kv: key must not consist solely of whitespace");
+        /* eslint-disable-next-line no-control-regex */
+        if (/[\x00-\x1F\x7F]/.test(key))
+            throw new Error("kv: key must not contain control characters");
         if (key.length > KV.KEY_MAX_LEN)
             throw new Error(`kv: key must be no longer than ${KV.KEY_MAX_LEN} characters`);
     }
@@ -33,7 +38,7 @@ export class KV {
     /*  set a value under the given key; overwrites any existing value  */
     static set(key, val) {
         KV.validateKey(key);
-        KV.store.set(key, val);
+        KV.store.set(key, structuredClone(val));
     }
     /*  delete a value by key; returns true if a value existed  */
     static delete(key) {
@@ -46,6 +51,16 @@ export class KV {
         KV.store.clear();
         return n;
     }
+    /*  snapshot the entire store into a fresh map (for transactional batch)  */
+    static snapshot() {
+        return new Map(KV.store);
+    }
+    /*  restore the store from a previously taken snapshot  */
+    static restore(snap) {
+        KV.store.clear();
+        for (const [k, v] of snap)
+            KV.store.set(k, v);
+    }
 }
 /*  MCP registration entry point for in-memory key/value tools  */
 export class KVMCP {
@@ -57,14 +72,14 @@ export class KVMCP {
                 "Returns the value as JSON-encoded `text`; returns an empty string if no value is stored.",
             inputSchema: {
                 key: z.string()
-                    .describe("key identifier (non-empty string, up to 1024 characters)")
+                    .describe("key identifier (non-empty, no whitespace-only, no control characters, up to 1024 characters)")
             }
         }, async (args) => {
             try {
                 if (!KV.has(args.key))
                     return { content: [{ type: "text", text: "" }] };
                 const val = KV.get(args.key);
-                const text = JSON.stringify(val);
+                const text = val === undefined ? "" : JSON.stringify(val);
                 return { content: [{ type: "text", text }] };
             }
             catch (err) {
@@ -80,8 +95,8 @@ export class KVMCP {
                 "The value can be any JSON-compatible type (string, number, boolean, null, array, object).",
             inputSchema: {
                 key: z.string()
-                    .describe("key identifier (non-empty string, up to 1024 characters)"),
-                val: z.any()
+                    .describe("key identifier (non-empty, no whitespace-only, no control characters, up to 1024 characters)"),
+                val: z.union([z.string(), z.number(), z.boolean(), z.null(), z.array(z.any()), z.record(z.string(), z.any())])
                     .describe("arbitrary JSON-compatible value to store under `key`")
             }
         }, async (args) => {
@@ -117,7 +132,7 @@ export class KVMCP {
                 "Returns a status `text` indicating whether a value existed and was removed.",
             inputSchema: {
                 key: z.string()
-                    .describe("key identifier (non-empty string, up to 1024 characters)")
+                    .describe("key identifier (non-empty, no whitespace-only, no control characters, up to 1024 characters)")
             }
         }, async (args) => {
             try {
@@ -132,5 +147,89 @@ export class KVMCP {
                 return { isError: true, content: [{ type: "text", text: `kv_delete: ERROR: ${message}` }] };
             }
         });
+        /*  key/value batch  */
+        mcp.registerTool("kv_batch", {
+            title: "ASE key/value batch",
+            description: "Execute an array of in-memory key/value `commands` in a single MCP call. " +
+                "Each entry is an object `{ command: \"clear\"|\"set\"|\"get\"|\"delete\", key?, val? }` " +
+                "and is dispatched to the corresponding single-op tool. " +
+                "If `transactional` is true, the store is snapshotted up-front and rolled back on the " +
+                "first per-command error (remaining commands are skipped); otherwise per-command errors " +
+                "are recorded and execution continues. " +
+                "Returns a single `text` payload containing a JSON array of per-command result strings " +
+                "in the same format emitted by `kv_clear`/`kv_set`/`kv_get`/`kv_delete`. " +
+                "On transactional rollback, prior per-command result strings are rewritten to " +
+                "`kv_<cmd>: ROLLED-BACK` to truthfully reflect the post-rollback state, and the " +
+                "final entry remains `kv_batch: ERROR: <message>`.",
+            inputSchema: {
+                commands: z.array(z.object({
+                    command: z.enum(["clear", "set", "get", "delete"])
+                        .describe("the KV sub-command to execute"),
+                    key: z.string().optional()
+                        .describe("key identifier (required for `set`/`get`/`delete`)"),
+                    val: z.union([z.string(), z.number(), z.boolean(), z.null(), z.array(z.any()), z.record(z.string(), z.any())]).optional()
+                        .describe("value to store (required for `set`)")
+                }))
+                    .describe("ordered list of KV commands to execute"),
+                transactional: z.boolean().optional()
+                    .describe("if true, snapshot the store and roll back on first error")
+            }
+        }, async (args) => {
+            const results = [];
+            const cmdNames = [];
+            const tx = args.transactional === true;
+            const snapshot = tx ? KV.snapshot() : null;
+            for (const c of args.commands) {
+                try {
+                    if (c.command === "clear") {
+                        const n = KV.clear();
+                        results.push(`kv_clear: OK: removed ${n} key(s)`);
+                        cmdNames.push("clear");
+                    }
+                    else if (c.command === "set") {
+                        if (c.key === undefined)
+                            throw new Error("kv_set: missing `key`");
+                        if (c.val === undefined)
+                            throw new Error("kv_set: missing `val`");
+                        KV.set(c.key, c.val);
+                        results.push(`kv_set: OK: stored key "${c.key}"`);
+                        cmdNames.push("set");
+                    }
+                    else if (c.command === "get") {
+                        if (c.key === undefined)
+                            throw new Error("kv_get: missing `key`");
+                        if (!KV.has(c.key))
+                            results.push("");
+                        else {
+                            const val = KV.get(c.key);
+                            results.push(val === undefined ? "" : JSON.stringify(val));
+                        }
+                        cmdNames.push("get");
+                    }
+                    else if (c.command === "delete") {
+                        if (c.key === undefined)
+                            throw new Error("kv_delete: missing `key`");
+                        const removed = KV.delete(c.key);
+                        results.push(removed ?
+                            `kv_delete: OK: removed key "${c.key}"` :
+                            `kv_delete: WARNING: no key "${c.key}" to remove`);
+                        cmdNames.push("delete");
+                    }
+                }
+                catch (err) {
+                    const message = err instanceof Error ? err.message : String(err);
+                    if (tx) {
+                        if (snapshot !== null)
+                            KV.restore(snapshot);
+                        for (let i = 0; i < results.length; i++)
+                            results[i] = `kv_${cmdNames[i]}: ROLLED-BACK`;
+                        results.push(`kv_batch: ERROR: ${message}`);
+                        return { isError: true, content: [{ type: "text", text: JSON.stringify(results) }] };
+                    }
+                    results.push(`kv_${c.command}: ERROR: ${message}`);
+                }
+            }
+            return { content: [{ type: "text", text: JSON.stringify(results) }] };
+        });
     }
 }

package/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "http://github.com/rse/ase",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "http://github.com/rse/ase/issues" },
-    "version":                              "0.0.41",
+    "version":                              "0.0.42",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

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

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.0.41",
+    "version":     "0.0.42",
     "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.0.41",
+    "version":     "0.0.42",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "http://github.com/rse/ase",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "http://github.com/rse/ase/issues" },
-    "version":                              "0.0.41",
+    "version":                              "0.0.42",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

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

@@ -33,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:
-
-   - During investigation in this STEP 1, do *not* output anything else,
-     especially do not give any further explanations or information.
-
-   - Focus on *practically relevant* cases and especially do *not*
-     investigate on theoretical or fictive cases.
-
-   - In case of problems related to *obvious or expected* errors,
-     they *should* be handled *near the origin*.
-
-   - 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.
-
-   - 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.
-
-   <template>
-   &#x1F7E0; PROBLEM (Severity: **<severity/>**): **P<n/>**: **<title/>**
-
-   <description/>
-   </template>
-
-   Hints:
-   - 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, ...
-
-   - In <description/>, use *very brief* but as *precise* as possible problem
-     descriptions.
-
-   - 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/>, 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>
-
-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>
+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.
+
+    Tenets:
+
+    -   **Quiet Operation**:
+        During investigation in this STEP 1, do *not* output anything else,
+        especially do not give any further explanations or information.
+
+    -   **Practical Relevance Only**:
+        Focus on *practically relevant* cases and especially do *not*
+        investigate on theoretical or fictive cases.
+
+    -   **Problem Focus Only**:
+        Still focus on the *problem only* and do *not* already
+        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.
+
+    <template>
+    &#x1F7E0; PROBLEM (Severity: **<severity/>**): **P<n/>**: **<title/>**
+
+    <description/>
+    </template>
+
+    Hints:
+
+    -   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, ...
+
+    -   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/>, 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>.
+
+    -   *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:
+
+    <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

@@ -121,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**:
 
@@ -167,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/>
@@ -199,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-refactor/SKILL.md

@@ -121,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**:
 
@@ -170,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/>
@@ -203,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

@@ -169,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**:
 
@@ -216,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/>
@@ -236,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/>
@@ -260,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`: