@rse/ase 0.9.16 → 0.9.18

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.16",
+    "version":                              "0.9.18",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -18,15 +18,15 @@
     "devDependencies": {
         "eslint":                           "9.39.4",
         "@eslint/js":                       "9.39.4",
-        "@typescript-eslint/parser":        "8.61.0",
-        "@typescript-eslint/eslint-plugin": "8.61.0",
+        "@typescript-eslint/parser":        "8.61.1",
+        "@typescript-eslint/eslint-plugin": "8.61.1",
         "eslint-plugin-promise":            "7.3.0",
         "eslint-plugin-import":             "2.32.0",
         "neostandard":                      "0.13.0",
         "globals":                          "17.6.0",
         "typescript":                       "6.0.3",
 
-        "@rse/stx":                         "1.1.5",
+        "@rse/stx":                         "1.1.6",
         "nodemon":                          "3.1.14",
         "shx":                              "0.4.0",
 
@@ -42,7 +42,7 @@
     },
     "dependencies": {
         "commander":                        "15.0.0",
-        "@dotenvx/dotenvx":                 "1.71.3",
+        "@dotenvx/dotenvx":                 "1.73.1",
         "yaml":                             "2.9.0",
         "valibot":                          "1.4.1",
         "execa":                            "9.6.1",
@@ -61,7 +61,7 @@
         "get-stdin":                        "10.0.0",
         "proper-lockfile":                  "4.1.2",
         "write-file-atomic":                "8.0.0",
-        "pacote":                           "21.5.1",
+        "pacote":                           "22.0.0",
         "ofetch":                           "1.5.1",
         "picomatch":                        "4.0.4"
     },

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

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.9.16",
+    "version":     "0.9.18",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/.codex-plugin/plugin.json

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

package/plugin/meta/ase-constitution.md

@@ -66,58 +66,7 @@ Commandments
   primary programming language* (e.g., TypeScript for TS/JS projects,
   Python for Python projects, Go for Go projects).
 
-Tenets
-------
-
-- **Think Before Coding**:
-  *Don't assume. Don't hide confusion. Surface tradeoffs.*
-  Before implementing:
-  - State your assumptions explicitly. If uncertain, ask.
-  - If multiple interpretations exist, present them - don't pick silently.
-  - If a simpler approach exists, say so. Push back when warranted.
-  - If something is unclear, stop. Name what's confusing. Ask.
-
-- **Simplicity First**:
-  *Minimum code that solves the problem. Nothing speculative.*
-  - No features beyond what was asked.
-  - No abstractions for single-use code.
-  - No "flexibility" or "configurability" that wasn't requested.
-  - No error handling for impossible scenarios.
-  - If you write 200 lines and it could be 50, rewrite it.
-  Ask yourself: "Would a senior software developer say this is overcomplicated?" If yes, simplify.
-
-- **Practical Relevance**:
-  *Error handling for practically relevant cases only. No theoretical assumptions.*
-  - Handle obvious or expected errors near the origin.
-  - Handle theoretical or unexpected errors in parent scopes.
-  - Avoid introducing dedicated state variables for individual error cases.
-  - If state variables are needed to detect error cases, use minimum number of those variables only.
-  - Use minimum number of state variables to span the maximum of error space.
-
-- **Surgical Changes**:
-  *Touch only what you must. Clean up only your own mess.*
-  When editing existing code:
-  - Don't "improve" adjacent code, comments, or formatting.
-  - Don't refactor things that aren't broken.
-  - Match existing style, even if you'd do it differently.
-  - If you notice unrelated dead code, mention it - don't delete it.
-  When your changes create orphans:
-  - Remove imports/variables/functions that YOUR changes made unused.
-  - Don't remove pre-existing dead code unless asked.
-  The test: Every changed line should trace directly to the user's request.
-
-- **Goal-Driven Execution**:
-  *Define success criteria. Loop until verified.*
-  Transform tasks into verifiable goals:
-  - "Add validation" → "Write tests for invalid inputs, then make them pass"
-  - "Fix the bug" → "Write a test that reproduces it, then make it pass"
-  - "Refactor X" → "Ensure tests pass before and after"
-  Strong success criteria let you loop independently.
-  Weak criteria ("make it work") require constant clarification.
-
-Persona
--------
+@./ase-tenets.md
 
 @./ase-control.md
 @./ase-persona.md
-

package/plugin/meta/ase-tenets.md

@@ -0,0 +1,220 @@
+
+The following are the **ASE Tenets** -- the guiding principles you
+*MUST* internalize and *honor at any time*. They are organized into
+*Generic Tenets*, which always apply, and *Operation-Specific Tenets*,
+which apply only to a particular kind of operation (Crafting, Aligning,
+Refactoring, Resolving).
+
+GENERIC TENETS
+--------------
+
+At any time and for all kinds of operations,
+you *MUST* honor the following so-called **GENERIC TENETS**:
+
+-   **Think Before Acting**:
+    *Don't assume. Don't hide confusion. Surface trade-offs.*
+    Before implementing:
+    -   State your assumptions explicitly. If uncertain, ask.
+    -   If multiple interpretations exist, present them - don't pick silently.
+    -   If a simpler approach exists, say so. Push back when warranted.
+    -   If something is unclear, stop. Name what's confusing. Ask.
+
+-   **Simplicity First**:
+    *Minimum solution that solves the problem. Nothing speculative.*
+    -   No features beyond what was asked.
+    -   No abstractions for single-use code.
+    -   No "flexibility" or "configurability" that wasn't requested.
+    -   No error handling for impossible scenarios.
+    -   If you write 200 lines and it could be 50, rewrite it.
+    Ask yourself: "Would a senior software developer say this is
+    overcomplicated?" If yes, simplify.
+
+-   **Practical Relevance**:
+    *Error handling for practically relevant cases only. No theoretical assumptions.*
+    -   Handle obvious or expected errors near the origin.
+    -   Handle theoretical or unexpected errors in parent scopes.
+    -   Avoid introducing dedicated state variables for individual error cases.
+    -   If state variables are needed to detect error cases, use minimum
+        number of those variables only.
+    -   Use minimum number of state variables to span the maximum of error space.
+
+-   **Surgical Changes**:
+    *Keep changes as small as possible.*
+    When editing existing code:
+    -   Touch only what you must. Clean up only your own mess.
+    -   Don't "improve" adjacent code, comments, or formatting.
+    -   Don't refactor things that aren't broken.
+    -   Match existing style, even if you'd do it differently.
+    -   If you notice unrelated dead code, mention it - don't delete it.
+    When your changes create orphans:
+    -   Remove imports/variables/functions that YOUR changes made unused.
+    -   Don't remove pre-existing dead code unless asked.
+    The test: Every changed line should trace directly to the user's request.
+
+-   **Separation of Concerns**:
+    *One concern per part; keep distinct concerns apart.*
+    -   Give each module, function, or layer a single, well-defined concern.
+    -   Don't entangle policy with mechanism, or business logic with I/O.
+    -   When one concern changes, the change should not ripple into unrelated ones.
+
+-   **Code Base Alignment**:
+    *Blend in. New aspect should read as if the existing aspects wrote it.*
+    -   Follow the established coding style, formatting, and idioms exactly.
+    -   Mirror the existing structure, layering, and file organization.
+    -   Reuse the prevailing naming conventions, patterns, and libraries.
+    -   When in doubt, imitate the nearest similar code rather than inventing anew.
+
+-   **Goal-Driven Execution**:
+    *Define success criteria. Loop until verified.*
+    Transform tasks into verifiable goals:
+    -   "Add validation" → "Write tests for invalid inputs, then make them pass"
+    -   "Fix the bug" → "Write a test that reproduces it, then make it pass"
+    -   "Refactor X" → "Ensure tests pass before and after"
+    Strong success criteria let you loop independently.
+    Weak criteria ("make it work") require constant clarification.
+
+CRAFTING TENETS
+---------------
+
+When *crafting* from scratch a new artifact, a feature, or an aspect,
+you *MUST* honor the following so-called "CRAFTING TENETS":
+
+-   **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.
+
+-   **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.
+
+-   **Single Responsibility Principle (SRP)**:
+    Every module, class, or function should have only one reason
+    to change.
+
+-   **Loose Coupling, High Cohesion**:
+    Strive 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.
+
+-   **Non-Functional Requirements**:
+    Honor the non-functional requirements Performance, Security,
+    Scalability, Comprehensibility.
+
+ALIGNING TENETS
+---------------
+
+When *aligning* a set of target artifacts to a set of source artifacts,
+you *MUST* honor the following so-called **ALIGNING TENETS**:
+
+-   **Directional Authority**:
+    The *source* artifacts are the single source of truth; only the
+    *target* artifacts are ever mutated. Never edit the source to fit
+    the target, and never let a stale target override a current source.
+
+-   **Faithful Reflection**:
+    The target *MUST* reflect the current source state *exactly* -- no
+    more, no less. Do not enrich the target with content the source does
+    not warrant, and do not silently drop source facts the target should
+    carry.
+
+-   **Drift Completeness**:
+    Detect *every* divergence between source and target, not just the
+    obvious additions: reconcile changed content, *and* remove or mark
+    target content that the source no longer supports (stale statements,
+    orphaned sections, dangling references).
+
+-   **No Fabrication**:
+    Never invent target content that the source does not support. If the
+    source is silent, ambiguous, or contradictory on something the target
+    needs, surface the gap explicitly rather than papering over it with a
+    plausible guess.
+
+-   **Level-Appropriate Translation**:
+    Re-express source facts at the *target's* level of abstraction and
+    altitude; do not copy verbatim across artifact levels. A SPEC states
+    intent, an ARCH states structure, CODE states realization, DOCS
+    states facts, etc -- align the *meaning*, not the wording.
+
+-   **Format Conformance**:
+    Keep every formatted target (SPEC, ARCH, TASK) conformant to its
+    format contract (headings, structure, identifiers). Treat CODE,
+    DOCS, INFR, and OTHR kinds of artifacts as foreign defined, but not
+    as free-form.
+
+-   **Alignment Traceability**:
+    Every target change *MUST* trace back to a concrete source fact. If
+    you cannot point to the source statement that justifies a target
+    edit, do not make that edit.
+
+REFACTORING TENETS
+------------------
+
+When *refactoring* existing artifacts or aspects,
+you *MUST* honor the following so-called **REFACTORING TENETS**
+
+-   **Behavior Preservation**:
+    Refactoring changes only re-structure, never change any
+    observable behavior at all. Especially, do not mix with
+    problem resolving and feature crafting.
+
+-   **Boy Scout Rule**:
+    After the refactoring, leave the source code base cleaner
+    than you found it.
+
+-   **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.
+
+-   **Single Responsibility Principle (SRP)**:
+    Every module, class, or function should have only one reason
+    to change.
+
+-   **Loose Coupling, High Cohesion**:
+    Strive 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.
+
+RESOLVING TENETS
+----------------
+
+When *resolving* a problem or challenge (bug-fixing),
+you *MUST* honor the following so-called **RESOLVING TENETS**
+
+-   **No Cleanups**:
+    Strictly focus on resolving the problem and do not mix the task with
+    any other necessary code cleanups, unless 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 generally and in parent
+    scopes.

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.16",
+    "version":                              "0.9.18",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -14,10 +14,10 @@
         "url":                              "http://engelschall.com"
     },
     "devDependencies": {
-        "@rse/stx":                         "1.1.5",
+        "@rse/stx":                         "1.1.6",
         "markdownlint":                     "0.41.0",
         "markdownlint-cli2":                "0.22.1",
-        "eslint":                           "10.4.1",
+        "eslint":                           "10.5.0",
         "@eslint/markdown":                 "8.0.2",
         "eslint-markdown":                  "0.11.0"
     },

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

@@ -132,58 +132,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Crafting Tenets">
 
-    You *MUST* internalize and honor the following tenets when crafting the new feature.
-    Do not output anything.
+    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
+        and the **CRAFTING TENETS** of the **ASE Tenets** when updating
+        in the following. Do not output anything.
 
-    1.  Generic Tenets:
-
-        -   **Separation of Concerns**:
-            Clearly separate all individual concerns as well 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.
-
-        -   **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.
-
-        -   **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.
-
-        -   **Single Responsibility Principle (SRP)**:
-            Every module, class, or function should have only one reason
-            to change.
-
-        -   **Loose Coupling, High Cohesion**:
-            Strive 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.
-
-        -   **Non-Functional Requirements**:
-            Honor the non-functional requirements Performance, Security,
-            Scalability, Comprehensibility.
+    2.  Do not output anything in this STEP 3.
 
     </step>
 

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

@@ -132,47 +132,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Refactoring Tenets">
 
-    You *MUST* internalize and honor the following tenets when refactoring.
-    Do not output anything.
+    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
+        and the **REFACTORING TENETS** of the **ASE Tenets** when updating
+        in the following. Do not output anything.
 
-    1.  Generic Tenets:
-
-        -   **Separation of Concerns**:
-            Clearly separate all individual concerns as well 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:
-
-        -   **Behavior Preservation**:
-            Refactoring changes only re-structure, never change any
-            observable behavior at all. Especially, do not mix with
-            problem resolving and feature crafting.
-
-        -   **Boy Scout Rule**:
-            After the refactoring, leave the source code base cleaner
-            than you found it.
-
-        -   **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.
-
-        -   **Single Responsibility Principle (SRP)**:
-            Every module, class, or function should have only one reason
-            to change.
-
-        -   **Loose Coupling, High Cohesion**:
-            Strive 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.
+    2.  Do not output anything in this STEP 3.
 
     </step>
 

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

@@ -186,45 +186,11 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 3.  <step id="STEP 3: Internalize Problem Resolution Tenets">
 
-    You *MUST* internalize and honor the following tenets when resolving the problem.
-    Do not output anything.
+    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
+        and the **RESOLVING TENETS** of the **ASE Tenets** when updating
+        in the following. Do not output anything.
 
-    1.  Generic Tenets:
-
-        -   **Separation of Concerns**:
-            Clearly separate all individual concerns as well 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.
-
-        -   **No Cleanups**:
-            Strictly focus on resolving the problem and do not mix this
-            task with any other necessary code cleanups, unless 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 generally and in parent scopes.
+    2.  Do not output anything in this STEP 3.
 
     </step>
 

package/plugin/skills/ase-meta-update/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: ase-meta-update
+argument-hint: "[--help|-h] <target>[,...] [<source>[,...]]"
+description: >
+    Update one set of artifact kinds (the target) to reflect the current
+    state of another set of artifact kinds (the source). Use when the
+    user wants to "update", "reconcile", or "sync" artifacts like SPEC,
+    ARCH, CODE, DOCS, TASK, INFR, or OTHR against each other.
+user-invocable: true
+disable-model-invocation: false
+effort: xhigh
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
+
+<skill name="ase-meta-update">
+    Update Artifacts from Artifacts
+</skill>
+
+<expand name="getopt" arg1="ase-meta-update">
+    $ARGUMENTS
+</expand>
+
+<objective>
+    *Update* the *target* artifact kinds to *reflect* the *current
+    state* of the *source* artifact kinds, by reading the source
+    artifacts and adjusting the target artifacts accordingly:
+    <request><getopt-arguments/></request>.
+</objective>
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-meta.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-spec.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-arch.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
+
+Procedure
+---------
+
+You *MUST* follow the following numbered items *strictly* *sequentially*!
+You *MUST* not skip any numbered item during processing!
+
+You *MUST* *NOT* output anything in this entire procedure, *except* when
+explicitly requested by this procedure via outputs based on a <template/>!
+
+<flow>
+
+1.  <step id="STEP 1: Determine Target and Source">
+
+    1.  The recognized artifact kinds are the seven tokens `TASK`,
+        `SPEC`, `ARCH`, `CODE`, `DOCS`, `INFR`, and `OTHR`. Parse
+        <getopt-arguments/> as one or two whitespace-separated fields:
+        the *first* field is the comma-separated <target/> kind list, the
+        optional *second* field is the comma-separated <source/> kind list.
+        Upper-case and trim every parsed kind token.
+
+    2.  <if condition="<target/> is empty">
+
+        Only output the following <template/> and then immediately *STOP*
+        processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-meta-update**, ▶ ERROR: missing target argument
+        </template>
+
+        </if>
+
+    3.  If any token in <target/> or <source/> is *not* one of the seven
+        recognized kinds, only output the following <template/> (with
+        <kind/> set to the first offending token) and then immediately
+        *STOP* processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-meta-update**, ▶ ERROR: unknown artifact kind: **<kind/>**
+        </template>
+
+    4.  <if condition="<source/> is empty">
+
+        Set <source/> to the seven recognized kinds
+        `TASK,SPEC,ARCH,CODE,DOCS,INFR,OTHR` *minus* all kinds present
+        in <target/> (preserving that fixed order). Do not output
+        anything.
+
+        </if>
+
+    5.  Remove from <source/> any kind that is also present in <target/>
+        (a kind is never its own source). If <source/> is then empty,
+        only output the following <template/> and then immediately *STOP*
+        processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-meta-update**, ▶ ERROR: empty source -- nothing to update from
+        </template>
+
+    6.  Report the resolved target and source with the following <template/>:
+
+        <template>
+        <ase-tpl-bullet-signal/> **TARGET**: <target/>
+        <ase-tpl-bullet-normal/> **SOURCE**: <source/>
+        </template>
+
+    </step>
+
+2.  <step id="STEP 2: Resolve and Read Artifact Files">
+
+    1.  Do not output anything in this STEP 2.
+
+    2.  For all kinds in the union of <target/> and <source/>,
+        call the `ase_artifact_list(kind: [ ... ])` tool of the `ase`
+        MCP server *once*, passing the lower-cased `kind` tokens, and
+        read the returned `artifacts` array of `{ kind, files }` objects
+        to obtain the project-relative file list per kind.
+
+    3.  Read all <source/> artifact files previously resolved and build a
+        precise understanding of the *current state* they represent.
+
+    </step>
+
+3.  <step id="STEP 3: Internalize Artifact Formats">
+
+    1.  Do not output anything in this STEP 3.
+
+    2.  Internalize and honor the artifact-format conventions imported above:
+        -   the artifact-set/artifact/aspect meta information of `ase-format-meta.md`,
+        -   the `SPEC` format of `ase-format-spec.md`,
+        -   the `ARCH` format of `ase-format-arch.md`,
+        -   the `TASK` format of `ase-format-task.md`.
+
+        Whenever a target artifact belongs to one of these formatted
+        kinds, the update *MUST* keep it conformant to the
+        corresponding format (headings, structure, identifiers, and the
+        `<timestamp-modified/>` rule). The kinds `CODE`, `DOCS`, `INFR`,
+        and `OTHR` have no dedicated format contract and are treated as
+        free-form.
+
+    </step>
+
+4.  <step id="STEP 4: Update Target Artifacts">
+
+    1.  You *MUST* internalize and strictly honor the **GENERIC TENETS**,
+        the **ALIGNMENT TENETS**, the **REFACTORING TENETS**, and the
+        **CRAFTING TENETS** of the **ASE Tenets** when updating in the following. Do not
+        output anything.
+
+    2.  *Update* the <target/> artifact files so that they faithfully
+        *reflect the current state* of the <source/> artifacts. Apply the
+        update *directly* to the target files via `Write`/`Edit`, keeping
+        changes as *surgical* as possible: change only what the source
+        state actually requires, and do *not* rewrite unrelated parts of a
+        target artifact.
+
+        For each formatted target kind, honor its format contract
+        internalized in STEP 3 and, whenever a target artifact is
+        changed, update its `<timestamp-modified/>` line via a call to
+        the `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the
+        `ase` MCP server.
+
+    3.  Report the performed update with the following <template/>, listing
+        one bullet line per changed target file (with <file/> its
+        project-relative path and <note/> an ultra-brief description of
+        what was reconciled):
+
+        <template>
+        <ase-tpl-bullet-signal/> **UPDATED ARTIFACTS**:
+
+        -   `<file/>`: <note/>
+        </template>
+
+        <if condition="no target artifact required any change">
+
+        Instead, only output the following <template/>:
+
+        <template>
+        <ase-tpl-bullet-normal/> **UPDATED ARTIFACTS**: none -- target already reflects source state.
+        </template>
+
+        </if>
+
+    </step>
+
+</flow>
+

package/plugin/skills/ase-meta-update/help.md

@@ -0,0 +1,66 @@
+
+##  NAME
+
+`ase-meta-update` - Update Artifacts from Artifacts
+
+##  SYNOPSIS
+
+`ase-meta-update`
+    [`--help`|`-h`]
+    *target*[,...]
+    [*source*[,...]]
+
+##  DESCRIPTION
+
+The `ase-meta-update` skill updates one set of artifact kinds (the
+*target*) to *reflect* the *current state* of another set of artifact
+kinds (the *source*). It reads the source artifacts and then adjusts the
+target artifacts *directly* and *surgically* to match the source state.
+
+Both *target* and *source* are comma-separated lists over the seven
+recognized artifact kinds `SPEC` (Specification), `ARCH` (Architecture),
+`CODE` (Source Code), `DOCS` (Documentation), `TASK` (Task Plans), `INFR`
+(Infrastructure), and `OTHR` (catch-all). When *source* is omitted, it
+defaults to all seven kinds *minus* the kinds listed in *target*. A kind
+present in *target* is never used as its own source.
+
+The file lists for the kinds `SPEC`, `ARCH`, `CODE`, `DOCS`, `INFR`, and
+`OTHR` are resolved via the `ase_artifact_list` MCP tool; the `TASK` kind
+is resolved generically from the `.ase/task/*/plan.md` task plans. While
+updating, the skill honors the artifact-format conventions of
+`ase-format-meta.md`, `ase-format-spec.md`, `ase-format-arch.md`, and
+`ase-format-task.md`; the kinds `CODE`, `DOCS`, `INFR`, and `OTHR` are
+treated as free-form.
+
+##  ARGUMENTS
+
+*target*[,...]:
+    The comma-separated list of artifact kinds to update.
+
+*source*[,...]:
+    The comma-separated list of artifact kinds to update *from*. When
+    omitted, it defaults to all recognized kinds except those in *target*.
+
+##  EXAMPLES
+
+Update the specification to reflect the current source code:
+
+```text
+❯ /ase-meta-update SPEC CODE
+```
+
+Update specification and architecture from everything else:
+
+```text
+❯ /ase-meta-update SPEC,ARCH
+```
+
+Update the documentation from the code and the architecture:
+
+```text
+❯ /ase-meta-update DOCS CODE,ARCH
+```
+
+##  SEE ALSO
+
+[`ase-meta-changelog`](../ase-meta-changelog/help.md), [`ase-arch-analyze`](../ase-arch-analyze/help.md), [`ase-arch-discover`](../ase-arch-discover/help.md).

package/dst/ase-notify.js

@@ -1,32 +0,0 @@
-/*
-**  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 { z } from "zod";
-/*  MCP registration entry point for user notification tool  */
-export class NotifyMCP {
-    register(mcp) {
-        mcp.registerTool("ase_notify", {
-            title: "ASE user notification",
-            description: "Display a `message` to the user in the terminal of the agent harness. " +
-                "The display happens deterministically through the accompanying PostToolUse hook, " +
-                "independent of any assistant text output. " +
-                "Use this to surface intermediate skill progress or status information " +
-                "which otherwise would not be visible to the user before the final response. " +
-                "Returns a status `text` acknowledging the notification.",
-            inputSchema: {
-                message: z.string().min(1).max(4096)
-                    .describe("message to display to the user (plain text, up to 4096 characters)")
-            }
-        }, async (args) => {
-            /*  the tool itself is a deliberate no-op: the user-visible display
-                happens in the PostToolUse hook ("ase hook post-tool-use"),
-                which receives this tool call's input from the agent harness
-                and reflects the message back as a "systemMessage"  */
-            return {
-                content: [{ type: "text", text: "notify: OK: message displayed to user" }]
-            };
-        });
-    }
-}