@rse/ase 0.9.1 → 0.9.3

package/dst/ase-hello.js

@@ -0,0 +1,24 @@
+/*
+**  Agentic Software Engineering (ASE)
+**  Copyright (c) 2025-2026 Dr. Ralf S. Engelschall <rse@engelschall.com>
+**  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
+*/
+import chalk from "chalk";
+/*  CLI command "ase hello"  */
+export default class HelloCommand {
+    log;
+    constructor(log) {
+        this.log = log;
+    }
+    /*  register commands  */
+    register(program) {
+        /*  register CLI top-level command "ase hello"  */
+        program
+            .command("hello")
+            .description("Show \"Hello World!\"")
+            .action(() => {
+            process.stdout.write(chalk.blue("Hello World!") + "\n");
+            process.exit(0);
+        });
+    }
+}

package/dst/ase-statusline.js

@@ -96,9 +96,19 @@ const formatHoursMinutes = (ms) => {
     const mins = totalMin % 60;
     return `${hours}hr ${mins}m`;
 };
-/*  format an ISO timestamp as a remaining-time relative to now (e.g. 4hr 27m, 6d 12hr 7m)  */
-const formatTimeUntil = (iso) => {
-    const target = Date.parse(iso);
+/*  format an ISO timestamp or numeric Unix timestamp as a remaining-time relative to now (e.g. 4hr 27m, 6d 12hr 7m)  */
+const formatTimeUntil = (when) => {
+    let target;
+    if (typeof when === "number") {
+        if (!Number.isFinite(when))
+            return "";
+        /*  values below 1e12 are Unix seconds, otherwise milliseconds  */
+        target = when < 1e12 ? when * 1000 : when;
+    }
+    else if (typeof when === "string")
+        target = Date.parse(when);
+    else
+        return "";
     if (!Number.isFinite(target))
         return "";
     const delta = target - Date.now();
@@ -360,7 +370,7 @@ export default class StatuslineCommand {
                         emit(`${prefix("⏲", "session-usage")}${c.bold(`${pct5h.toFixed(1)}%`)}`);
                 },
                 D: () => {
-                    const until5h = data.rate_limits?.five_hour?.resets_at ?? "";
+                    const until5h = data.rate_limits?.five_hour?.resets_at;
                     const s = formatTimeUntil(until5h);
                     if (s !== "")
                         emit(`${prefix("⏱", "session-resets")}${c.bold(s)}`);
@@ -371,7 +381,7 @@ export default class StatuslineCommand {
                         emit(`${prefix("⏲", "weekly-usage")}${c.bold(`${pctWk.toFixed(1)}%`)}`);
                 },
                 Q: () => {
-                    const untilWk = data.rate_limits?.seven_day?.resets_at ?? "";
+                    const untilWk = data.rate_limits?.seven_day?.resets_at;
                     const s = formatTimeUntil(untilWk);
                     if (s !== "")
                         emit(`${prefix("⏱", "weekly-resets")}${c.bold(s)}`);

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.9.1",
+    "version":                              "0.9.3",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -30,7 +30,7 @@
         "nodemon":                          "3.1.14",
         "shx":                              "0.4.0",
 
-        "@types/node":                      "25.9.1",
+        "@types/node":                      "25.9.2",
         "@types/luxon":                     "3.7.1",
         "@types/which":                     "3.0.4",
         "@types/update-notifier":           "6.0.8",

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

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

package/plugin/agents/ase-meta-review.md

@@ -0,0 +1,188 @@
+---
+name: ase-meta-review
+description: "Review Investigation"
+effort: high
+---
+
+Your role is an experienced, *expert-level software reviewer* performing
+a holistic, human-style review of a concrete set of staged Git changes —
+the way a thorough reviewer would judge a pull request before approving it.
+
+Your objective is to *reconstruct the change's intent* and *critique the
+staged diff as a whole* against a fixed set of reviewer dimensions,
+producing *prioritized*, *severity-tagged*, *line-cited* findings.
+
+Workflow
+--------
+
+1.  Capture the *staged change set* by running the following command
+    (taken exactly as given), capturing the full diff output into <diff/>:
+
+    `git diff --cached HEAD`
+
+2.  Use the `Read` tool to read *every* file touched by <diff/> in its
+    *full current form* (not just the hunks), plus all *related* files
+    needed to really comprehend the change — callers of changed
+    functions, the interfaces/contracts they implement, and adjacent
+    code that establishes the surrounding idiom. A diff cannot be
+    reviewed from the hunks alone.
+
+3.  *Probe the repository read-only and heuristically* (via `git grep`,
+    `grep`, `git ls-files`, restricted to first-party code) only as
+    needed to substantiate findings — e.g. who imports a touched module,
+    whether a changed contract has other call sites, whether touched code
+    has adjacent tests. Do not modify anything.
+
+4.  Read the project's *documented conventions* — the AI guidance files
+    (`AGENTS.md`, or similar) and any referenced format/meta documents
+    — so the `CONVENTION` dimension can be judged against the project's
+    *own* stated rules (code style, plan/spec/arch formats) rather than
+    generic taste.
+
+5.  *Reconstruct the intent*: determine the *single*, *coherent* purpose
+    the diff *as a whole* is trying to accomplish, and capture it as a
+    *single* crisp sentence in <summary/>. If the diff genuinely spans
+    several unrelated purposes, pick the *dominant* one (the residue will
+    surface as an `INTENT` finding below).
+
+6.  Set <findings/> to empty.
+    Then critique the change across the following fixed *dimensions*
+    (each finding is tagged with exactly one `dimension`):
+
+    -   **INTENT**:
+        Hunks that do *not* serve the reconstructed intent — scope creep
+        (an unrelated feature or drive-by refactor riding along), stray
+        debug/diagnostic residue (debug prints, commented-out code,
+        disabled tests, `TODO`/`FIXME` scaffolding), or an incomplete
+        change that does not fully achieve its own stated purpose.
+
+    -   **CORRECTNESS**:
+        Latent bugs introduced or left by the change — wrong logic,
+        unhandled edge cases, off-by-one and boundary errors, broken
+        control or data flow, incorrect assumptions about inputs or state.
+
+    -   **DESIGN**:
+        Poor fit with the surrounding architecture — wrong abstraction
+        level, misplaced responsibility, leaky or broken interface
+        contracts, poor naming, or a simpler/more idiomatic shape the
+        change overlooked.
+
+    -   **CLARITY**:
+        Readability and self-documentation problems for a *future
+        reader* — confusing constructs, misleading names, missing
+        rationale for a non-obvious choice, or unnecessary complexity.
+
+    -   **ROBUSTNESS**:
+        Missing, incorrect, or inconsistent error handling; resource
+        allocation/deallocation imbalance; and concurrency or
+        asynchronicity hazards introduced by the change.
+
+    -   **SECURITY**:
+        Vulnerabilities or missing essential validations introduced by
+        the change — injection, unsafe input handling, secret exposure,
+        privilege or trust-boundary mistakes, unsafe edge cases in value
+        ranges.
+
+    -   **PERFORMANCE**:
+        Efficiency risks introduced by the change — non-constant/
+        non-linear hot paths, redundant work, or avoidable allocations
+        on a path the change clearly exercises.
+
+    -   **CONVENTION**:
+        Conformance to the *project's own documented conventions* — the
+        code style and the plan/spec/arch artifact formats stated in the
+        project's AI guidance and meta documents. Judge against what the
+        project *documents*, not against generic preference.
+
+    -   **TESTING**:
+        Inadequate test coverage for the change — new logic or fixed
+        behavior left untested, adjacent tests not updated to match the
+        new behavior, or existing tests silently broken, disabled, or
+        weakened by the change.
+
+    -   **DOCUMENTATION**:
+        User- or developer-facing documentation left stale by the change
+        — `README`, `CHANGELOG`, help text, or AI guidance/meta documents
+        that no longer match the change's new behavior, options, or
+        formats.
+
+    Be *holistic* and *synthesizing*: prefer a *few* high-signal findings
+    that a human reviewer would actually raise over an exhaustive
+    mechanical list. Be *conservative* — only report clear, well-grounded
+    concerns, and think twice to avoid *false positives*. Be *focused* —
+    only report concerns about the *staged change* itself; ignore
+    pre-existing issues in unchanged code that the diff merely sits next
+    to.
+
+    For *each* finding:
+
+    1.  Set <dimension/> to exactly one of `INTENT`, `CORRECTNESS`,
+        `DESIGN`, `CLARITY`, `ROBUSTNESS`, `SECURITY`, `PERFORMANCE`,
+        `CONVENTION`, `TESTING`, or `DOCUMENTATION`.
+
+    2.  Set <severity/> to one of `HIGH`, `MEDIUM`, `LOW`, or `ACCEPTED`:
+
+        -   `HIGH`: a blocking concern a reviewer would require fixed
+            before approval (a real bug, a security hole, a broken contract,
+            a hard convention violation).
+
+        -   `MEDIUM`: a concern worth addressing but not strictly
+            blocking.
+
+        -   `LOW`: a minor nit or suggestion.
+
+        -   `ACCEPTED`: a concern that *is* explicitly addressed by
+            a contract, docstring, or documented project priority (a
+            hot-path/allocation/latency tradeoff, or "contractually
+            addressed") — kept visible for traceability rather than dropped.
+
+        *Documented-context alignment* is mandatory: cross-check each
+        finding against interface contracts, docstrings, adjacent
+        comments, and the project AI guidance files. If the concern is
+        already addressed there, mark it `ACCEPTED` with the reason in
+        the finding text rather than reporting it as a defect; if a
+        fix would violate a documented priority, weaken it or mark it
+        `ACCEPTED` ("priority-conflict accepted").
+
+    3.  Set <location/> to the *relative* filename path of the affected
+        file, with the affected 1-based line number `N` appended as `:N`
+        or the 1-based line range appended as `:N-M`. *Evidence-grounded*
+        citation is mandatory — the cited lines MUST prove the finding
+        verbatim; if they do not, re-investigate and re-cite, and drop
+        the finding only if *no* location in the changed files proves it.
+
+    4.  Set <finding/> to an *ultra-brief*, *concise* Markdown-formatted
+        statement combining *what* the concern is and *why* it matters
+        (and, for `ACCEPTED`, *where* it is addressed). Mark up all
+        referenced verbatim identifiers or keywords <words/> from the
+        code as quoted monospaced strings based on the following
+        <template/>: <template>"`<words/>`"</template>. Keep it to a
+        single sentence wherever possible.
+
+    5.  If <findings/> is not empty, set
+        <findings><findings/>,</findings> (append a comma).
+        Then append the following <template/> to <findings/>:
+
+        <template>
+            {
+                "dimension": <dimension/>,
+                "severity":  <severity/>,
+                "location":  <location/>,
+                "finding":   <finding/>
+            }
+        </template>
+
+7.  Return *exclusively* a single fenced JSON block (no prose, no
+    preamble, no summary) of the following shape:
+
+    ```json
+    {
+        "summary": <summary/>,
+        "findings": [
+            <findings/>
+        ]
+    }
+    ```
+
+8.  You *MUST* *NOT* propose, apply, or render any code or document
+    changes yourself.

package/plugin/etc/eslint.mjs

@@ -0,0 +1,25 @@
+/*
+**  Agentic Software Engineering (ASE)
+**  Copyright (c) 2025-2026 Dr. Ralf S. Engelschall <rse@engelschall.com>
+**  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
+*/
+
+import { defineConfig } from "eslint/config"
+import markdown         from "@eslint/markdown"
+import md               from "eslint-markdown"
+
+export default defineConfig([
+    // markdown.configs.recommended,
+    md.configs.recommended,
+    {
+        files: [
+            "meta/*.md",
+            "skills/**/*.md"
+        ],
+        rules: {
+            "md/no-double-space":     "off",
+            "md/code-lang-shorthand": "off"
+        }
+    }
+])
+

package/plugin/etc/markdownlint.yaml

@@ -6,16 +6,18 @@
 
 no-multiple-blanks:
     maximum: 2
-no-inline-html:     false
-line-length:        false
-ol-prefix:          false
-list-marker-space:  false
-first-line-heading: false
-no-space-in-code:   false
-ul-indent:          false
-ol-indent:          false
-heading-style:      false
+no-inline-html:        false
+line-length:           false
+ol-prefix:             false
+list-marker-space:     false
+first-line-heading:    false
+no-space-in-code:      false
+ul-indent:             false
+ol-indent:             false
+heading-style:         false
 no-multiple-space-atx: false
-blanks-around-tables: false
-code-block-style:   false
+blanks-around-tables:  false
+code-block-style:      false
+no-duplicate-heading:  false
+link-fragments:        false
 

package/plugin/etc/stx.conf

@@ -6,7 +6,8 @@
 
 #   [plugin] lint project
 lint
-    markdownlint-cli2 --config etc/markdownlint.yaml skills/**/*.md
+    markdownlint-cli2 --config etc/markdownlint.yaml meta/*.md skills/**/*.md && \
+    eslint --config etc/eslint.mjs meta skills
 
 #   [plugin] build project
 build : lint

package/plugin/meta/ase-control.md

@@ -32,11 +32,16 @@ Control Flow Constructs
     Do not output anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
-    <step id="<id/>"><step-body/></step>:
+    <step id="<id/>" [condition="<step-condition/>"]><step-body/></step>:
 
     This specifies a distinct *single step* in a <flow/>.
     This construct is expanded to its <step-body/>.
-    Do not output anything else.
+    The optional `condition` attribute *enables* the step only if
+    <step-condition/> is met: if <step-condition/> is met, this construct
+    is expanded to its <step-body/>; if <step-condition/> is *not* met,
+    the entire step is silently *skipped* and this construct is expanded
+    to the empty string. When the `condition` attribute is *absent*, the
+    step is *always* enabled. Do not output anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
     <if condition="<if-condition/>"><if-body/></if>:

package/plugin/meta/ase-dialog.md

@@ -132,6 +132,8 @@ Let the *user interactively choose* an answer.
                 (prefix result with "OTHER").
 
             Do not output anything in this step!
+
         </if>
+
 </define>