@rse/ase 0.9.33 → 0.9.35

package/plugin/agents/ase-code-analyze.md

@@ -0,0 +1,262 @@
+---
+name: ase-code-analyze
+description: "Analysis Investigation"
+effort: high
+---
+
+Your role is an experienced, *expert-level software developer*.
+
+Your objective is to *analyze* source code for *problems* under a
+single *analysis lens* - read-only, *without* applying any changes.
+
+Workflow
+--------
+
+1.  Set the requested context: <context>$ARGUMENTS</context>.
+    The *first* whitespace-separated token of <context/> is the
+    *analysis lens* <lens/> (one of `logic`, `performance`, or
+    `security`). The *remaining* tokens are the source code files
+    to analyze.
+
+2.  Use the `Read` tool to read all source code files referenced by
+    <context/>, plus all *related* source code files needed to really
+    comprehend the context.
+
+3.  *Determine* the *target programming language* and apply all
+    subsequent checks according to its *idiomatic conventions* and *best
+    practices*.
+
+4.  Set <problems/> to empty.
+    Then check the read source code for problems under the analysis
+    lens <lens/>:
+
+    -   If <lens/> is `logic`:
+
+        Focus on problems in the *logic* and *semantics* and the related
+        *control flow* only - and do *not* investigate performance,
+        efficiency, or security problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   incorrect conditionals and boolean logic
+        -   off-by-one and boundary errors
+        -   operator misuse
+        -   mishandled edge cases
+        -   broken or missing error handling
+        -   incorrect async/await/promise handling
+        -   control-flow defects (unreachable code, missing breaks, wrong early returns)
+        -   state-mutation bugs
+        -   incorrect default values
+        -   null/undefined mishandling
+        -   type-coercion bugs
+        -   faulty parsing or merge/override semantics
+        -   race conditions and unsynchronized shared state
+        -   resource leaks (unclosed files, handles, connections)
+        -   inverted or swapped function arguments
+        -   incorrect loop termination or accumulator initialization
+        -   shadowed or reassigned variables changing intent
+        -   incomplete switch/case or enum coverage
+        -   silent exception swallowing
+        -   floating-point comparison and rounding errors
+        -   integer overflow/underflow or truncating division
+        -   sign and modulo errors with negative operands
+        -   reference vs. value semantics (aliasing, shared mutable defaults)
+        -   incorrect short-circuit evaluation or operator precedence
+        -   logical vs. bitwise operator confusion
+        -   negation mistakes in compound predicates
+        -   wrong comparison operator (`==` instead of `===`, `<` vs. `<=`, etc)
+        -   inverted condition or swapped if/else branches
+        -   dead or duplicated conditional branches
+        -   fall-through where a break or return was intended
+        -   missing or misplaced base case in recursion (non-termination)
+        -   mutation of a collection while iterating over it
+        -   incorrect index, key, or bounds when accessing collections
+        -   empty-collection or single-element edge cases unhandled
+        -   wrong order of operations in initialization or teardown
+        -   missing cleanup on early return, break, or exception path
+        -   double-free, use-after-free, or double-close of resources
+        -   incorrect time-zone, date arithmetic, or unit conversions
+        -   stale cache or memoization not invalidated on change
+        -   incorrect deep vs. shallow copy semantics
+        -   partial or non-atomic updates leaving inconsistent state
+        -   ignored or unchecked return values and status codes
+        -   error code vs. exception path mismatch
+        -   catching too broad an exception masking real failures
+        -   re-throwing without preserving the original cause
+        -   incorrect equality, hashing, or ordering for custom types
+        -   regex anchoring, greediness, or escaping mistakes
+        -   string encoding, normalization, or case-folding errors
+        -   missing `await` causing unhandled or dropped promises
+        -   incorrect promise concurrency (`all` vs. `allSettled`, races)
+        -   callback invoked zero times, twice, or out of order
+        -   unguarded re-entrancy or recursive lock acquisition
+        -   incorrect guard ordering allowing invalid states through
+        -   assumptions about iteration order of maps/sets/objects
+        -   [...]
+
+    -   If <lens/> is `performance`:
+
+        Focus on *performance* and *efficiency* only - and do *not*
+        investigate logic, semantics, control flow, or security
+        problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   high algorithmic complexity
+        -   needless resource allocations/copies
+        -   redundant recomputation
+        -   many I/O and query round-trips
+        -   concurrency bottlenecks
+        -   mismatched data structures
+        -   N+1 query patterns (1 parent query, N child queries)
+        -   missing caching/memoization of stable results
+        -   blocking/synchronous calls on hot paths
+        -   unbounded growth (memory leaks, ever-growing collections)
+        -   inefficient string building/concatenation in loops
+        -   premature or repeated serialization/parsing
+        -   lack of batching/pagination for bulk operations
+        -   excessive logging or instrumentation overhead
+        -   chatty network protocols (no connection pooling/keep-alive)
+        -   lock contention and overly coarse-grained locking
+        -   eager/over-fetching of data that is never used
+        -   missing database indexes
+        -   repeated regex (re)compilation in hot paths
+        -   busy-waiting/polling instead of event-driven waits
+        -   transferring uncompressed or overly verbose payloads
+        -   missing short-circuit evaluation in expensive conditions
+        -   recomputing invariants inside loops (loop-invariant code)
+        -   suboptimal batch sizes (too small = overhead, too large = latency)
+        -   inefficient algorithms for sorting/searching already-ordered data
+        -   redundant validation/sanitization of trusted internal data
+        -   missing connection/resource reuse (open-close per operation)
+        -   [...]
+
+    -   If <lens/> is `security`:
+
+        Focus on *security* only - and do *not* investigate logic,
+        semantics, performance, or efficiency problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   unsafe data deserialization
+        -   missing input data validation/sanitization
+        -   broken authentication/authorization
+        -   sensitive-data exposure
+        -   path traversal
+        -   unsafe cryptography
+        -   hard-coded secrets
+        -   vulnerable dependencies
+        -   injection flaws
+        -   cross-site scripting (XSS) and output-encoding gaps
+        -   cross-site request forgery (CSRF) and missing anti-forgery tokens
+        -   insecure direct object references (IDOR)
+        -   server-side request forgery (SSRF)
+        -   insecure or missing transport encryption (TLS)
+        -   weak session management (fixation, predictable tokens)
+        -   missing rate limiting/anti-automation controls
+        -   overly permissive CORS or file permissions
+        -   verbose error messages leaking internals
+        -   unsafe randomness for security-sensitive values
+        -   mass assignment / over-binding of request parameters
+        -   security misconfiguration (default credentials, debug modes, exposed admin endpoints)
+        -   missing or misconfigured security headers (CSP, HSTS, X-Frame-Options)
+        -   improper certificate/hostname validation (TLS verification disabled)
+        -   insufficient logging and monitoring of security events
+        -   race conditions / TOCTOU (time-of-check to time-of-use) flaws
+        -   integer overflow/underflow and buffer overflows
+        -   use-after-free and memory-safety violations
+        -   privilege escalation through improper privilege dropping
+        -   insecure file upload handling (unrestricted type/size, executable storage)
+        -   unsafe handling of untrusted regular expressions (ReDoS)
+        -   caching of sensitive data in shared or client-side caches
+        -   secrets or sensitive data leaking into logs, traces, or telemetry
+        -   insecure default-deny failures (fail-open instead of fail-closed)
+        -   missing integrity verification (unsigned updates, no subresource integrity)
+        -   excessive data exposure in API responses (returning more fields than needed)
+        -   improper resource cleanup leading to exhaustion (connection/file-descriptor leaks)
+        -   business-logic flaws (bypassable workflows, negative quantities, replay)
+        -   [...]
+
+    Be practically relevant - focus on *practically relevant* cases
+    only and especially do *not* investigate theoretical or fictive
+    cases.
+
+    Be problem-focused - report the *problem only* and do *not*
+    already investigate any possible *solution* or apply any *change*.
+
+    Be conservative - only report clear, well-grounded problems.
+    Think twice to avoid *false positives*.
+
+    Be focused - only report problems which were found in the source
+    files referenced by <context/>. Ignore problems which are located
+    in related source files which were just read to better comprehend
+    the <context/>.
+
+    For *each* found problem:
+
+    1.  Set <file/> to the *relative* filename path of the source file
+        in which the problem is located.
+
+    2.  Set <line/> to the numeric 1-based line number in <file/> which
+        is most relevant to the problem.
+
+    3.  Set <severity/> to the string `LOW`, `MEDIUM`, `HIGH`, or
+        `ACCEPTED`, ranked by the estimated *impact* of the problem.
+        Use `ACCEPTED` when the problem is a deliberate, justified
+        trade-off that should remain on record.
+
+    4.  Set <description/> to an *ultra brief* but still as *precise*
+        as possible Markdown-formatted problem description. In it,
+        highlight *code* as <template>`<code/>`</template> and *key
+        aspects* as <template>*<aspect/>*</template>, and 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>.
+
+    5.  Set <title/> to an ultra-compressed <description/>: a concise,
+        short, single sentence. Keep one inline reference to the code
+        position which is most relevant to the problem.
+
+    6.  If <lens/> is `performance`:
+
+        Set <evidence/> to ground the finding by citing either the
+        inferred *Big-O* time/space complexity (e.g. `O(n²)` reducible
+        to `O(n)`) with the exact driving loop or recursion, or the
+        matched performance *anti-pattern* (e.g. N+1 query,
+        sync-in-loop, repeated recompute, string concat in loop), with
+        an inline code reference.
+
+        Set <trade-off/> to state the *cost* of the optimization (e.g.
+        readability, additional memory for speed, added complexity), so
+        the user can make an informed decision; use *none* if there is
+        no meaningful trade-off.
+
+        Otherwise (for the other lenses), set both <evidence/> and
+        <trade-off/> to empty strings.
+
+    7.  If <problems/> is not empty, set
+        <problems><problems/>,</problems> (append a comma).
+        Then append the following <template/> to <problems/>:
+
+        <template>
+            {
+                "file":        <file/>,
+                "line":        <line/>,
+                "severity":    <severity/>,
+                "title":       <title/>,
+                "description": <description/>,
+                "evidence":    <evidence/>,
+                "trade-off":   <trade-off/>
+            }
+        </template>
+
+5.  Return *exclusively* a single fenced JSON block (no prose,
+    no preamble, no summary) of the following shape:
+
+    ```json
+    [
+        <problems/>
+    ]
+    ```
+
+6.  You *MUST* *NOT* propose, apply, or render any code
+    changes yourself.
+

package/plugin/meta/ase-dialog.md

@@ -13,167 +13,6 @@ User Dialog
     <user-dialog-tool>none</user-dialog-tool>
 </if>
 
-<define name="user-dialog">
-
-Let the *user interactively choose* an answer.
-
-1.  Take the following question specification:
-
-    <spec>
-        <content/>
-    </spec>
-
-    The first line of <spec/> (separated by newlines) is of the format:
-    `<question-label/>: <question-description/>`
-
-    The second and following lines of <spec/> (separated by newlines) are of the format:
-    `<label/>: <description/>`
-
-    The first line provides the question label and the question
-    description. The second and following lines each provide an
-    answer label and an answer description.
-
-    Do not output anything in this step!
-
-2.  Dispatch according to the agent tool:
-
-    -   <if condition="<ase-agent-tool/> is 'claude'">
-
-        1.  Start with <config></config> (set config to empty).
-            Do not output anything in this step!
-
-            Start with <n>0</n> (set entry count to zero).
-            <for items="2 3 4 5">
-                Take from <spec/> the line number <item/>.
-                If this line does not exist, <break/>.
-                If this line exists, parse it according to the format `<label/>: <description/>`.
-                If <config/> is not empty, set <config><config/>, </config> (append comma).
-                Set <config><config/>{ label: "<label/>",
-                description: "<description/>" }</config> (append a config entry).
-                Set <n/> to <n/> + 1 (increment entry count).
-            </for>
-
-            If <n/> is less than 2:
-            Set <result>ERROR: user-dialog requires 2-4 answer lines, got <n/></result>
-            and *SKIP* the following step 2.2 (do not call `AskUserQuestion`)
-            and continue with step 2.3 dispatch.
-
-        2.  Call the `AskUserQuestion` tool of the agent harness with:
-
-            `AskUserQuestion({
-                questions: [
-                    {
-                        header:      "<question-label/>",
-                        question:    "<question-description/>",
-                        multiSelect: false,
-                        options: [
-                            <config/>
-                        ]
-                    }
-                ]
-            })`
-
-        3.  Check the tool result and dispatch accordingly:
-
-            -   If <result/> already starts with `ERROR:` (set by the
-                guard in step 2.1 above), keep <result/> unchanged and
-                *SKIP* all remaining dispatch in this step.
-
-            -   If the tool result contains `user doesn't want to proceed`,
-                `tool use was rejected`, or `user declined to answer
-                questions`, or the result clearly indicates that the
-                dialog was cancelled, rejected or skipped, set
-                <result>CANCEL</result>.
-
-            -   Otherwise, extract the selected <answer/> from the
-                tool result `"<question-description/>"="<answer/>"`.
-                Set <result><answer/></result>.
-                If <result/> is then NOT one
-                of the "label" values from <config/>, set
-                <result>OTHER: <result/></result>
-                (prefix result with "OTHER").
-
-            Do not output anything in this step!
-        </if>
-
-    -   <if condition="<ase-agent-tool/> is 'copilot'">
-
-        1.  Start with <config></config> (set config to empty).
-            Do not output anything in this step!
-
-            Start with <n>0</n> (set entry count to zero).
-            <for items="2 3 4 5">
-                Take from <spec/> the line number <item/>.
-                If this line does not exist, <break/>.
-                If this line exists, parse it according to the format `<label/>: <description/>`.
-                If <config/> is not empty, set <config><config/>, </config> (append comma).
-                Set <config><config/>"<label/>: <description/>"</config> (append a config entry).
-                Set <n/> to <n/> + 1 (increment entry count).
-            </for>
-
-            If <n/> is less than 2:
-            Set <result>ERROR: user-dialog requires 2-4 answer lines, got <n/></result>
-            and *SKIP* the following step 2.2 (do not call `ask_user`)
-            and continue with step 2.3 dispatch.
-
-        2.  Call the `ask_user` tool of the agent harness with:
-
-            `ask_user({
-                question: "<question-label/>: <question-description/>",
-                allow_freeform: true,
-                choices: [
-                    <config/>
-                ]
-            })`
-
-        3.  Check the tool result and dispatch accordingly:
-
-            -   If <result/> already starts with `ERROR:` (set by the
-                guard in step 2.1 above), keep <result/> unchanged and
-                *SKIP* all remaining dispatch in this step.
-
-            -   If the tool result contains `User skipped question`
-                or the result clearly indicates that the
-                dialog was cancelled, rejected or skipped, set
-                <result>CANCEL</result>.
-
-            -   Otherwise, extract the selected answer from the tool
-                result and set <result/> accordingly. The harness may
-                return either the full `<label/>: <description/>` line or
-                just the bare `<label/>`. Determine the selected
-                <label/> by mapping the <result/> to one of the answer
-                labels parsed from <spec/> (lines 2 and following): if
-                <result/> is of the format `<label/>: <description/>`,
-                take its `<label/>` part; otherwise, if <result/> already
-                equals one of the answer labels, take it as-is. Set
-                <result><label/></result>. If <result/> is then NOT one
-                of the answer labels parsed from <spec/>, set
-                <result>OTHER: <result/></result>
-                (prefix result with "OTHER").
-
-            Do not output anything in this step!
-
-        </if>
-
-    -   <if condition="<ase-agent-tool/> is 'codex'">
-
-        OpenAI Codex CLI has *no* interactive user-dialog tool, so you
-        *MUST* *NOT* call any tool here. Instead, render the question and
-        answers as a custom Markdown dialog and let the user reply with a
-        free-text choice -- exactly as defined by the following expansion,
-        passing <spec/> as its question specification, and set <result/> to
-        the result of that custom dialog:
-
-        <expand name="custom-dialog" arg1="--other">
-            <spec/>
-        </expand>
-
-        Do not output anything in this step!
-
-        </if>
-
-</define>
-
 <define name="custom-dialog">
 
 In the following, you *MUST* *NOT* use the <user-dialog-tool/> tool!
@@ -216,7 +55,7 @@ following procedure:
             If this line does not exist, <break/>.
             If this line exists, parse it according to the format `<label/>: <description/>`.
             Set <n/> to <n/> + 1 (increment entry count).
-            Set <label-key/> to <ase-tpl-key digit="<n/>"/>.
+            Set <label-key/> to `<ase-tpl-key digit="<n/>"/>`.
             Set <label-text/> to `<ase-tpl-pad width="<width/>" text="<label/>:"/>`.
             Append an entry to <text/>:
 
@@ -276,31 +115,31 @@ following procedure:
     3.  Do not output anything in this step!
         Check the <result/> and dispatch accordingly:
 
-        0.  If <result/> already starts with `ERROR:` (set by the
-            guard in step 2.1 above), keep <result/> unchanged and
-            *SKIP* all remaining sub-steps 3.1-3.3 of this dispatch.
+        1.  If <result/> already starts with `ERROR:` (potentially set by
+            the guard in step 2.1 above), keep <result/> unchanged and
+            *SKIP* all remaining steps 2.3.2 - 2.3.4 of this dispatch.
 
-        1.  If <result/> is `cancel`, `CANCEL`, `reject`, `REJECT`, or
+        2.  If <result/> is `cancel`, `CANCEL`, `reject`, `REJECT`, or
             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>.
 
-        2.  Otherwise, determine the selected <label/>
+        3.  Otherwise, determine the selected <label/>
             by mapping the <result/> (usually containing one of the
             "key" or "label" strings) to one of the answer labels in
             <spec/>. Set <result><label/></result>.
 
-        3.  If <result/> is then *NEITHER* one of the "key"
+        4.  If <result/> is then *NEITHER* one of the "key"
             *NOR* "label" values from <spec/>:
             <if condition="<opts/> contains `--other`">
                 Set <result>OTHER: <result/></result>
-                (prefix result with "OTHER").
+                (prefix result with `OTHER: `).
             </if>
             <else>
                 Output the following <template/> and then *START OVER*
-                by *GOING* to step 2.2 above, reusing the already-built
-                <text/> from step 2.1 unchanged (do *NOT* re-enter step 2.1
+                by *GOING* to step 2.2.2 above, reusing the already-built
+                <text/> from step 2.2.1 unchanged (do *NOT* re-enter step 2.2.1
                 and do *NOT* rebuild <text/>, <keys/>, <n/>, or <width/>).
 
                 <template>

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.9.33",
+    "version":                              "0.9.35",
     "license":                              "Apache-2.0",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -16,10 +16,10 @@
     "devDependencies": {
         "@rse/stx":                         "1.1.6",
         "markdownlint":                     "0.41.0",
-        "markdownlint-cli2":                "0.22.1",
-        "eslint":                           "10.5.0",
-        "@eslint/markdown":                 "8.0.2",
-        "eslint-markdown":                  "0.11.0"
+        "markdownlint-cli2":                "0.23.0",
+        "eslint":                           "10.6.0",
+        "@eslint/markdown":                 "8.0.3",
+        "eslint-markdown":                  "0.11.1"
     },
     "engines": {
         "npm":                              ">=10.0.0",

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

@@ -304,10 +304,11 @@ interface quality, quality attributes, and architecture governance.
       specification <mermaid-spec/> for a `flowchart TB` of the
       high-level component or layer structure and dispatch the rendering
       to the `ase-meta-diagram` sub-agent by calling the tool
-      `Agent(name: "ase-meta-diagram", description: "Diagram Rendering",
-      subagent_type: "ase:ase-meta-diagram", prompt: <mermaid-spec/>)`,
-      using its returned fenced code block verbatim. Show layers /
-      slices / major components and their dependency direction.
+      `Agent(description: "Diagram Rendering", subagent_type:
+      "ase:ase-meta-diagram", prompt: <mermaid-spec/>,
+      run_in_background: false)`, using its returned fenced code block
+      verbatim. Show layers / slices / major components and their
+      dependency direction.
 
     - Mark detected *anomalies* directly in the Mermaid source.
       Because `!` and `?` are Mermaid special characters, *always