chore: replace em and en dashes with ASCII throughout

.devcontainer/devcontainer.json

@@ -1,6 +1,6 @@
 // Webware alignment Dev Container.
 //
-// This is a thin wrapper around compose.yml — it reuses the `tooling` service
+// This is a thin wrapper around compose.yml - it reuses the `tooling` service
 // rather than defining a parallel environment, so VS Code and plain
 // `docker compose` users share the exact same container. Non-VS Code
 // developers are not orphaned: they use `docker compose up -d` +

.github/copilot-instructions.md

@@ -1,12 +1,12 @@
-# Webware Admin — Copilot Agent Instructions
+# Webware Admin: Copilot Agent Instructions
 
-## Read this before acting — fleet working agreements
+## Read this before acting: fleet working agreements
 
 `vendor/webware/webware-tools/agent-working-agreements.md` is authoritative for how work is done
 in this fleet, and it overrides anything else in this file or in any local note. Read it before
 acting, and again before reporting. The non-negotiables:
 
-- Do exactly the scope asked — only the files, branches and repositories named. No adjacent edits,
+- Do exactly the scope asked - only the files, branches and repositories named. No adjacent edits,
   no cleanup, no onboarding, no surveys.
 - Anything else you notice gets one line at most, with no proposed fix.
 - Never close a reply with a condensed restatement of it, and never present an inference as a
@@ -21,22 +21,22 @@ PHPUnit 13 enforces a strict separation between mocks and stubs. Violating these
 
 - **Use `createStub()`** when the test double only needs to return values (`method()->willReturn()`, `method()->willReturnCallback()`). No expectations are configured.
 - **Use `createMock()`** only when the test verifies behavior with `expects()` (e.g. `expects($this->once())`, `expects($this->never())`).
-- **Never** call `createMock()` without also calling `expects()` on at least one method — PHPUnit 13 will issue a notice.
+- **Never** call `createMock()` without also calling `expects()` on at least one method - PHPUnit 13 will issue a notice.
 - **Remove** `/** @var ClassName&MockObject */` annotations and `MockObject` intersection types on variables created with `createStub()`.
 - **Remove** the `use PHPUnit\Framework\MockObject\MockObject;` import from any file where no `createMock()` + `expects()` usage remains.
 
 ### Examples
 
 ```php
-// CORRECT — stub returns value, no expectations
+// CORRECT - stub returns value, no expectations
 $container = $this->createStub(ContainerInterface::class);
 $container->method('get')->willReturnCallback(static fn(string $id): mixed => ...);
 
-// CORRECT — mock verifies behavior with expects()
+// CORRECT - mock verifies behavior with expects()
 $handler = $this->createMock(ErrorHandler::class);
 $handler->expects($this->once())->method('attachListener');
 
-// WRONG — createMock() with no expects() triggers PHPUnit notice
+// WRONG - createMock() with no expects() triggers PHPUnit notice
 $logger = $this->createMock(Logger::class);
 $logger->method('withName')->willReturn($logger); // should be createStub()
 ```
@@ -45,6 +45,6 @@ $logger->method('withName')->willReturn($logger); // should be createStub()
 
 `phpunit.xml.dist` has `requireCoverageMetadata="true"`. Every test class **must** have:
 
-1. `#[CoversClass(ClassName::class)]` — one per source class under test.
-2. `#[CoversMethod(ClassName::class, 'methodName')]` — one per public/protected method exercised.
+1. `#[CoversClass(ClassName::class)]` - one per source class under test.
+2. `#[CoversMethod(ClassName::class, 'methodName')]` - one per public/protected method exercised.
 3. `use PHPUnit\Framework\Attributes\CoversClass;` and `use PHPUnit\Framework\Attributes\CoversMethod;` imports.

.github/skills/speckit-analyze/SKILL.md

@@ -60,7 +60,7 @@ Identify inconsistencies, duplications, ambiguities, and underspecified items ac
 
 **STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
 
-**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit-analyze`.
+**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks - not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit-analyze`.
 
 ## Execution Steps
 
@@ -83,7 +83,7 @@ Load only the minimal necessary context from each artifact:
 
 - Overview/Context
 - Functional Requirements
-- Success Criteria (measurable outcomes — e.g., performance, security, availability, user success, business impact)
+- Success Criteria (measurable outcomes - e.g., performance, security, availability, user success, business impact)
 - User Stories
 - Edge Cases (if present)
 

.github/skills/speckit-checklist/SKILL.md

@@ -107,11 +107,11 @@ You **MUST** consider the user input before proceeding (if not empty).
       - Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
       - Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
       - Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
-      - Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?")
+      - Scenario class gap (e.g., "No recovery flows detected - are rollback / partial failure paths in scope?")
 
    Question formatting rules:
    - If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
-   - Limit to A–E options maximum; omit table if a free-form answer is clearer
+   - Limit to A - E options maximum; omit table if a free-form answer is clearer
    - Never ask the user to restate what they already said
    - Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope."
 

.github/skills/speckit-clarify/SKILL.md

@@ -128,7 +128,7 @@ Execution steps:
 4. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
     - Maximum of 5 total questions across the whole session.
     - Each question must be answerable with EITHER:
-       - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR
+       - A short multiple‑choice selection (2-5 distinct, mutually exclusive options), OR
        - A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words").
     - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
     - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.
@@ -140,7 +140,7 @@ Execution steps:
     - Present EXACTLY ONE question at a time.
     - **Question writing quality (applies to every question, MC or short-answer):**
        - Lead with `**Question:**` followed by a full interrogative that ends with `?`. The question text before the `?` must make sense on its own.
-       - NEVER use a topic label, section heading, or requirement id as the question itself. For example, `Acceptance device/runtime matrix (FR-023)` is INVALID — it is a label, not a question.
+       - NEVER use a topic label, section heading, or requirement id as the question itself. For example, `Acceptance device/runtime matrix (FR-023)` is INVALID - it is a label, not a question.
        - After the `?`, the only permitted suffix is an optional parenthesized requirement/question id. Exact format: `**Question:** <interrogative>?` or `**Question:** <interrogative>? (FR-023)`. Never put the id before the `?`, and never use the id (alone or with a topic label) as the whole prompt.
        - Immediately after the question line, add one plain-language "Why it matters" sentence (the stake for acceptance or shipping) before the recommendation/options.
        - Use everyday wording; introduce jargon only if defined in the same sentence. Self-check: a reader who does not know Spec Kit must be able to answer from the Question line alone. Terse is fine; cryptic labels are not.
@@ -211,14 +211,14 @@ Execution steps:
    - If it does NOT exist, skip this step silently.
    - If it exists:
      1. Read the checklist file.
-     2. Identify all GitHub task-list checkbox lines — lines matching `- [ ]`, `- [x]`, or `- [X]` (case-insensitive, tolerant of leading whitespace for nested items) outside of code fences. Ignore all other content (headings, notes, non-checkbox bullets, metadata).
+     2. Identify all GitHub task-list checkbox lines - lines matching `- [ ]`, `- [x]`, or `- [X]` (case-insensitive, tolerant of leading whitespace for nested items) outside of code fences. Ignore all other content (headings, notes, non-checkbox bullets, metadata).
      3. For each checkbox line, record its current marker state (checked or unchecked) and item text into a before-snapshot list.
      4. Re-evaluate each checkbox item against the **updated** spec (the version just saved in step 7).
      5. For each checkbox item, update only if the checked/unchecked state actually changes:
         - If the item now passes and was unchecked: change `[ ]` to `[x]`.
         - If the item now fails and was checked: change `[x]`/`[X]` to `[ ]`.
         - If the state is unchanged: leave the marker as-is (preserve existing case to avoid cosmetic diffs).
-     6. Save the updated checklist file. **Only toggle the `[ ]`/`[x]` marker portion of checkbox lines whose state changed.** All other file content — headings, metadata, notes, line ordering, whitespace — must remain unchanged to avoid noisy diffs.
+     6. Save the updated checklist file. **Only toggle the `[ ]`/`[x]` marker portion of checkbox lines whose state changed.** All other file content - headings, metadata, notes, line ordering, whitespace - must remain unchanged to avoid noisy diffs.
      7. Compare the before-snapshot with the current state to compute three lists for the Completion Report:
         - **Newly passing**: items that changed from unchecked to checked.
         - **Regressions**: items that changed from checked to unchecked.
@@ -251,7 +251,7 @@ Check if `.specify/extensions.yml` exists in the project root.
   - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
 - When constructing command invocations from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `/speckit-git-commit`.
 - For each executable hook, output the following based on its `optional` flag:
-  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
+  - **Mandatory hook** (`optional: false`) - **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
     ```
     ## Extension Hooks
 
@@ -278,7 +278,7 @@ Report completion (after questioning loop ends or early termination):
 - Number of questions asked & answered.
 - Path to updated spec.
 - Sections touched (list names).
-- Spec quality checklist status (if `FEATURE_DIR/checklists/requirements.md` was re-validated): show before/after pass counts (e.g., "Spec Quality Checklist: 12/16 → 15/16 items passing") and list any items that changed state — both newly checked (unchecked → checked) and any regressions (checked → unchecked). If any items remain unchecked, list them as areas needing attention.
+- Spec quality checklist status (if `FEATURE_DIR/checklists/requirements.md` was re-validated): show before/after pass counts (e.g., "Spec Quality Checklist: 12/16 → 15/16 items passing") and list any items that changed state - both newly checked (unchecked → checked) and any regressions (checked → unchecked). If any items remain unchecked, list them as areas needing attention.
 - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
 - If any Outstanding or Deferred remain, recommend whether to proceed to `/speckit-plan` or run `/speckit-clarify` again later post-plan.
 - Suggested next command.

.github/skills/speckit-constitution/SKILL.md

@@ -103,7 +103,7 @@ Follow this execution flow:
    - If version bump type ambiguous, propose reasoning before finalizing.
 
 3. Draft the updated constitution content using the resolved template as the required structure:
-   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet - explicitly justify any left).
    - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
    - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
    - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.

.github/skills/speckit-converge/SKILL.md

@@ -69,7 +69,7 @@ of remaining work as a new, traceable task** at the bottom of `tasks.md` so that
 `/speckit-implement` has run on the current `tasks.md`, and after `/speckit-tasks` has produced a complete `tasks.md`.
 
 This is **not** a diff tool and does **not** track changes. It assesses the present state
-of the code relative to the feature's artifacts — no git, no branch comparison, no history.
+of the code relative to the feature's artifacts - no git, no branch comparison, no history.
 
 ## Operating Constraints
 
@@ -79,7 +79,7 @@ of the code relative to the feature's artifacts — no git, no branch comparison
 - modify `spec.md` or `plan.md` in any way;
 - rewrite, renumber, reorder, or delete any existing task (including tasks from a prior
   Convergence phase);
-- modify, create, or delete any application code — completing the appended tasks is the
+- modify, create, or delete any application code - completing the appended tasks is the
   job of `/speckit-implement`.
 
 When the codebase already satisfies everything, the command MUST leave `tasks.md`
@@ -112,7 +112,7 @@ Load only the minimal necessary context from each artifact:
 **From spec.md:**
 
 - Functional Requirements (FR-###)
-- Success Criteria (SC-###) — include only items requiring buildable work; exclude
+- Success Criteria (SC-###) - include only items requiring buildable work; exclude
   post-launch outcome metrics and business KPIs
 - User Stories and their Acceptance Scenarios
 - Edge Cases (if present)
@@ -142,7 +142,7 @@ Create an internal model (do not echo raw artifacts):
   impose buildable obligations.
 - **Code-scope map**: from the file paths named in `plan.md` and `tasks.md`, plus a keyword
   search for the concepts each requirement describes, derive the set of source files and
-  components in scope for assessment. Bound the assessment to these — do **not** infer
+  components in scope for assessment. Bound the assessment to these - do **not** infer
   scope beyond what the artifacts define.
 
 ### 4. Assess the Codebase and Classify Findings
@@ -156,7 +156,7 @@ For each item in the intent inventory, inspect the current code in scope and pro
 - **`contradicts`**: the code does something that conflicts with stated intent or a
   constitution MUST principle.
 - **`unrequested`**: the code contains work not called for by the spec, plan, or tasks
-  (surfaced for awareness — converge does **not** delete code, it only appends a task to
+  (surfaced for awareness - converge does **not** delete code, it only appends a task to
   review/justify or remove it).
 
 Each `Finding` records: a stable id, the `source-ref` it traces to, the `gap-type`, a
@@ -192,7 +192,7 @@ Before appending anything, output a compact, severity-graded summary (no file wr
 
 - Requirements / acceptance criteria checked
 - Plan decisions checked
-- Constitution principles checked (or "skipped — template")
+- Constitution principles checked (or "skipped - template")
 - Findings by gap type (missing / partial / contradicts / unrequested)
 - Findings by severity
 
@@ -220,12 +220,12 @@ Append to the **end** of `tasks.md`, per the append contract:
    Constitution-violation tasks MUST be emitted first and described as
    `CRITICAL`.
 4. Never reuse or renumber existing IDs. If a prior Convergence phase exists, add a new,
-   separately-numbered one below it — do not touch the old one.
+   separately-numbered one below it - do not touch the old one.
 
 **If there are no actionable findings** (`converged` outcome):
 
-- Do **not** modify `tasks.md` at all — no empty phase header.
-- Report: **"✅ Converged — the implementation satisfies the spec, plan, and tasks."**
+- Do **not** modify `tasks.md` at all - no empty phase header.
+- Report: **"✅ Converged - the implementation satisfies the spec, plan, and tasks."**
 - Include the summary counts of what was checked.
 
 ### 8. Provide Next Actions (Handoff)

.github/skills/speckit-implement/SKILL.md

@@ -193,7 +193,7 @@ Check if `.specify/extensions.yml` exists in the project root.
   - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
 - When constructing command invocations from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `/speckit-git-commit`.
 - For each executable hook, output the following based on its `optional` flag:
-  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
+  - **Mandatory hook** (`optional: false`) - **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
     ```
     ## Extension Hooks
 

.github/skills/speckit-plan/SKILL.md

@@ -80,7 +80,7 @@ Check if `.specify/extensions.yml` exists in the project root.
   - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
 - When constructing command invocations from hook command names, replace dots (`.`) with hyphens (`-`). For example, `speckit.git.commit` → `/speckit-git-commit`.
 - For each executable hook, output the following based on its `optional` flag:
-  - **Mandatory hook** (`optional: false`) — **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
+  - **Mandatory hook** (`optional: false`) - **You MUST emit `EXECUTE_COMMAND:` for each mandatory hook**:
     ```
     ## Extension Hooks