@karmaniverous/stan-core 0.4.7 → 0.5.0

package/dist/stan.system.md

@@ -11,7 +11,9 @@
 6. Coverage: one Patch per changed file. Full Listings are not required by default in normal replies; include them only on explicit request. Diagnostics replies require Full Listings only (no patches). Skip listings for deletions.
 7. Services‑first: ports & adapters; thin adapters; pure services; co‑located tests.
 8. Long‑file rule: ~300 LOC threshold; propose splits or justify exceptions; record plan/justification in stan.todo.md.
-9. Fence hygiene: choose fence length dynamically (max inner backticks + 1); re‑scan after composing. **Table of Contents**
+9. Fence hygiene: wrap code blocks in tilde fences (default `~~~~`), bump to `~`×(N+1) when content contains `~`×N; re‑scan after composing.
+
+**Table of Contents**
 
 - Role
 - Vocabulary aliases
@@ -280,22 +282,26 @@ When the unexpected happens, a short design iteration almost always produces a b
 # Dependency Bug Report
 
 Purpose
+
 - When a dependency fails, offer a concise, valid‑Markdown bug report that upstream (human or STAN) can consume.
 - Keep the report self‑contained (short excerpts inline). Prefer links for large evidence; defer artifacts to a later iteration.
 
 Fence hygiene
-- When presenting this template in chat, wrap the entire template body in a fence chosen by the Fence Hygiene (Quick How‑To) algorithm and re‑scan before sending. Do not rely on a fixed backtick count.
+
+- When presenting this template in chat, wrap the entire template body in a fence chosen by the Fence Hygiene (Quick How‑To) algorithm and re‑scan before sending. Do not rely on a fixed tilde count.
 
 Canonical template (copy/paste the body; wrap per fence‑hygiene rules)
 
 # Dependency Bug Report — <package>@<version>
 
 ## Summary
+
 - What: <1–2 sentences describing the failure in downstream usage>
 - Where: <downstream repo name> (<relative paths>)
 - Impact: <blocking | partial | annoyance>; Scope: <modules affected>
 
 ## Environment
+
 - Downstream repo: <name> @ <commit or tag>
 - Node: <x.y.z> (<os/arch>)
 - Package manager: <npm|pnpm|yarn> <version>
@@ -303,11 +309,13 @@ Canonical template (copy/paste the body; wrap per fence‑hygiene rules)
 - Tooling: TypeScript <x.y>, Bundler <rollup/vite/webpack>, ESLint/TSConfig notes (if relevant)
 
 ## Reproduction (minimal)
-1) <command or step>
-2) <command or step>
-3) Observe: <expected vs actual>
+
+1. <command or step>
+2. <command or step>
+3. Observe: <expected vs actual>
 
 Example:
+
 ```bash
 pnpm i
 pnpm run build
@@ -316,12 +324,15 @@ pnpm run build
 ```
 
 ## Evidence (concise)
+
 Primary error excerpt:
+
 ```text
 <copy the minimal error lines + 2–5 lines of context>
 ```
 
 If a minimal code change triggers it, show the tiniest diff:
+
 ```diff
 diff --git a/src/example.ts b/src/example.ts
 --- a/src/example.ts
@@ -332,29 +343,35 @@ diff --git a/src/example.ts b/src/example.ts
 ```
 
 ## Root cause hypothesis (best‑effort)
+
 - <e.g., subpath export missing; ESM/CJS mismatch; types not published; side effects; changed API signature>
 - Why we think so: <brief rationale, links to docs/source lines>
 
 ## Proposed fix (what we need from upstream)
-1) <concrete change, e.g., “add subpath export ./mutator in package.json”>
-2) <build/output change, e.g., “publish .d.ts alongside JS outputs”>
-3) <docs note or migration guidance, if applicable>
+
+1. <concrete change, e.g., “add subpath export ./mutator in package.json”>
+2. <build/output change, e.g., “publish .d.ts alongside JS outputs”>
+3. <docs note or migration guidance, if applicable>
 
 ## Acceptance criteria
+
 - After publishing:
   - <import/build/test> succeeds without local hacks.
   - TypeScript resolves types without path alias overrides.
   - No <specific error codes/warnings> remain in a fresh install.
 
 ## Attachments or links (evidence)
+
 - Preferred: links to logs, a minimal repro repo, or a PR that demonstrates the issue clearly.
 - Avoid bundling artifacts in the same message as this report to prevent ingestion confusion by tools that auto‑process archives.
 
 ## Notes for downstream (we’ll handle)
+
 - <local pin/guard we will apply temporarily; removed after fix>
 - <config/doc updates we’ll make once published>
 
 ## Maintainer contact
+
 - Upstream repo: <url>
 - Issue link (if already filed): <url or “to be filed”>
 
@@ -1057,7 +1074,7 @@ If info is insufficient to proceed without critical assumptions, abort and clari
 ## Commit message output
 
 - MANDATORY: Commit message MUST be wrapped in a fenced code block.
-  - Use a plain triple-backtick fence (or longer per the fence hygiene rule if needed).
+  - Use a tilde fence (default `~~~~`, or longer per the fence hygiene rule if needed).
   - Do not annotate with a language tag; the block must contain only the commit message text.
   - Emit the commit message once, at the end of the reply.
   - This rule applies to every change set, regardless of size.
@@ -1069,7 +1086,7 @@ If info is insufficient to proceed without critical assumptions, abort and clari
     - “When: <UTC timestamp>”
     - “Why: <short reason>”
     - “What changed:” bulleted file list with terse notes
-- The fenced commit message MUST be placed in a code block fence that satisfies the +1 backtick rule (see Response Format).
+- The fenced commit message MUST be placed in a code block fence that satisfies the tilde fence hygiene rule (see Response Format).
 - When patches are impractical, provide Full Listings for changed files, followed by the commit message. Do not emit unified diffs in that mode.
 
 Exception — patch failure diagnostics:
@@ -1081,29 +1098,47 @@ Exception — patch failure diagnostics:
 
 # Fence Hygiene (Quick How‑To)
 
-Goal: prevent hashed or broken templates/examples that contain nested code blocks.
+Goal: prevent broken Markdown when emitting fenced blocks, especially diffs and
+Markdown listings that contain embedded backtick fences.
 
-Algorithm
-1) Scan every block you will emit (patches, templates, examples). Compute the maximum contiguous run of backticks inside each block’s content.
-2) Choose the outer fence length as N = (max inner backticks) + 1 (minimum 3).
-3) Re‑scan after composing. If any block’s outer fence is ≤ the max inner run, bump N and re‑emit.
+Default wrapper
+
+- Use **tilde fences** for all fenced code blocks we emit (Patch blocks, Full
+  Listings, templates/examples, and Commit Message blocks).
+- Start with a **default fence of `~~~~`** (4 tildes). Tilde fences are valid
+  Markdown but rare in code/docs, so collisions are much less common than with
+  backtick fences.
+
+Algorithm (tilde-based)
+
+1) Scan every block you will emit. Compute the maximum contiguous run of `~`
+   characters that appears anywhere in that block’s content.
+2) Choose the outer fence length as `N = max(4, maxInnerTildes + 1)`.
+3) Emit the block wrapped in `~`×N.
+4) Re‑scan after composing. If any block’s outer fence is `<= maxInnerTildes`,
+   bump N and re‑emit.
 
 Hard rule (applies everywhere)
-- Do not rely on a fixed backtick count. Always compute, then re‑scan.
-- This applies to the Dependency Bug Report template, patch failure diagnostics envelopes, and any example that includes nested fenced blocks.
+- Do not rely on a fixed tilde count. Always compute, then re‑scan.
+- This applies to Patch blocks, Full Listings, the Dependency Bug Report
+  template, patch-failure diagnostics envelopes, and any example that includes
+  fenced blocks.
 
 # Response Format (MANDATORY)
 
 CRITICAL: Fence Hygiene (Nested Code Blocks) and Coverage
 
-- You MUST compute fence lengths dynamically to ensure that each outer fence has one more backtick than any fence it contains.
+- Use **tilde fences** for all fenced blocks emitted in replies (Patch blocks,
+  Full Listings, and Commit Message). Default is `~~~~`.
+- You MUST compute fence lengths dynamically to ensure that each outer fence has
+  one more `~` than any `~` run it contains (minimum 4).
 - Algorithm:
   1. Collect all code blocks you will emit (every “Patch” per file; any optional “Full Listing” blocks, if requested).
-  2. For each block, scan its content and compute the maximum run of consecutive backticks appearing anywhere inside (including literals in examples).
-  3. Choose the fence length for that block as maxInnerBackticks + 1 (minimum 3).
-  4. If a block contains other fenced blocks (e.g., an example that itself shows fences), treat those inner fences as part of the scan. If the inner block uses N backticks, the enclosing block must use at least N+1 backticks.
+  2. For each block, scan its content and compute the maximum run of consecutive `~` characters appearing anywhere inside (including literals in examples).
+  3. Choose the fence length for that block as `max(4, maxInnerTildes + 1)`.
+  4. If a block contains other fenced blocks (e.g., an example that itself shows fences), treat those inner fences as part of the scan. If the inner content uses `~`×N, the enclosing block must use at least `~`×(N+1).
   5. If a file has both a “Patch” and an optional “Full Listing”, use the larger fence length for both blocks.
-  6. Never emit a block whose outer fence length is less than or equal to the maximum backtick run inside it.
+  6. Never emit a block whose outer fence length is less than or equal to the maximum `~` run inside it.
   7. After composing the message, rescan each block and verify the rule holds; if not, increase fence lengths and re‑emit.
 
 General Markdown formatting
@@ -1137,10 +1172,10 @@ Use these headings exactly; wrap each Patch (and optional Full Listing, when app
 
 <change summary>
 
-```
+~~~~
 ### File Ops
 <one operation per line>
-```
+~~~~
 
 ## Input Data Changes
 
@@ -1172,17 +1207,17 @@ Use these headings exactly; wrap each Patch (and optional Full Listing, when app
 
 ## Commit Message
 
-- Output the commit message at the end of the reply wrapped in a fenced code block. Do not annotate with a language tag. Apply the +1 backtick rule. The block contains only the commit message (subject + body), no surrounding prose.
+- Output the commit message at the end of the reply wrapped in a fenced code block. Do not annotate with a language tag. Apply the tilde fence-hygiene rule. The block contains only the commit message (subject + body), no surrounding prose.
 
 ## Validation
 
 - Normal replies:
   - Confirm one Patch block per changed file (and zero Full Listings).
-  - Confirm fence lengths obey the +1 backtick rule for every block.
+  - Confirm fence lengths obey the tilde fence hygiene rule for every block.
   - Confirm that no Patch would cause any file to exceed 300 LOC; pivoted decomposition patches instead.
 - Diagnostics replies (after patch‑failure envelopes):
   - Confirm that the reply contains Full Listings only (no patches), one per affected file (union across envelopes).
-  - Confirm fence lengths obey the +1 backtick rule for every block.
+  - Confirm fence lengths obey the tilde fence hygiene rule for every block.
   - Confirm that no listed file exceeds 300 LOC; if it would, pivoted decomposition + listings for the decomposed files instead.
 
 ---
@@ -1205,7 +1240,7 @@ Before sending a reply, verify all of the following:
    - Diagnostics replies (after patch‑failure envelopes): Do NOT emit a Commit Message.
 
 3. Fence hygiene (+1 rule)
-   - For every fenced block, the outer fence is strictly longer than any internal backtick run (minimum 3).
+   - For every fenced block, the outer fence is strictly longer than any internal `~` run (minimum 4).
    - Patches, optional Full Listings, and commit message all satisfy the +1 rule.
 4. Section headings
    - Headings match the template exactly (names and order).
@@ -1214,7 +1249,7 @@ Before sending a reply, verify all of the following:
    - Normal replies: If any Patch block is present, there MUST also be a Patch for <stanPath>/system/stan.todo.md that reflects the change set (unless the change set is deletions‑only or explicitly plan‑only). The “Commit Message” MUST be present and last.
    - Diagnostics replies: Skip Commit Message; listings‑only for the affected files.
 6. Nested-code templates (hard gate)
-   - Any template or example that contains nested fenced code blocks (e.g., the Dependency Bug Report or a patch failure diagnostics envelope) MUST pass the fence‑hygiene scan: compute N = maxInnerBackticks + 1 (min 3), apply that fence, then re‑scan before sending. If any collision remains, STOP and re‑emit. If any check fails, STOP and re‑emit after fixing. Do not send a reply that fails these checks.
+   - Any template or example that contains nested fenced code blocks (e.g., the Dependency Bug Report or a patch failure diagnostics envelope) MUST pass the fence‑hygiene scan: compute N = max(4, maxInnerTildes + 1), apply that tilde fence, then re‑scan before sending. If any collision remains, STOP and re‑emit. If any check fails, STOP and re‑emit after fixing. Do not send a reply that fails these checks.
 7. Dev plan “Completed” (append‑only; last)
    - If `.stan/system/stan.todo.md` is patched:
      - “Completed” is still the final major section of the document.

package/dist/types/index.d.ts

@@ -246,6 +246,10 @@ type FileOp = {
     verb: 'mv';
     src: string;
     dest: string;
+} | {
+    verb: 'cp';
+    src: string;
+    dest: string;
 } | {
     verb: 'rm';
     src: string;

package/package.json

@@ -152,5 +152,5 @@
   },
   "type": "module",
   "types": "dist/index.d.ts",
-  "version": "0.4.7"
+  "version": "0.5.0"
 }