@aperant/framework 0.8.1 → 0.8.6

package/skills/apt-planner.md

@@ -59,7 +59,7 @@ For STANDARD and COMPLEX tasks:
 
 ## 4. Write Specification
 
-Content format branches on track (Pocock adoption ID-05, Fast Path Guarantee).
+Content format branches on track.
 
 ### 4.A. QUICK track / SIMPLE complexity — legacy 4-section spec
 
@@ -100,6 +100,17 @@ Content format branches on track (Pocock adoption ID-05, Fast Path Guarantee).
 ## User Stories
 {**US-NN (persona).** stories, 1:1 onto subtasks.}
 
+## User Outcomes
+{Verify-proof input contract. **Epic:** headline + N atomic outcomes.
+Authors write the LITERAL `**ON**` string (IDs are POSITIONAL — parser
+synthesizes O1/O2/…). Closed surface set:
+`electron | web | cli | api | electron+web`. Empty-with-note escape:
+`_No user-observable changes — pure refactor._`}
+
+**Epic:** {one-sentence user-facing capability}
+
+- **ON** [surface]: {user does X; system shows/does Y}
+
 ## Implementation Decisions
 {### ID-NN load-bearing principles.}
 
@@ -120,6 +131,11 @@ PRD section ordering is load-bearing — downstream tooling greps by header.
 Do NOT interview the user; synthesize from task description + codebase +
 AGENTS.md.
 
+**`## User Outcomes` synthesis directive.** Outcomes are
+user-observable; ACs are code-level. Do NOT collapse — they parse
+through different gates. STANDARD/DEEP specs carry both. IDs are
+POSITIONAL — never hand-author `**O1**`/`**O2**`.
+
 ## 5. Create Implementation Plan
 
 Create `{task_dir}/implementation_plan.json`:

package/skills/apt-pr-review/SKILL.md

@@ -1081,7 +1081,7 @@ For every finding with `validation_status == "confirmed_valid"` AND `severity
    - `{REVIEWER_EVIDENCE}` — the finding's `evidence` field verbatim.
 3. Invoke codex using the shape configured at `.aperant/config.json:router.llm.providers.codex`:
    ```bash
-   codex exec --model gpt-5.3-codex --input-file /tmp/fp-gate-${FINDING_ID}.md
+   codex exec --input-file /tmp/fp-gate-${FINDING_ID}.md
    ```
    Parse the JSON response `{verdict, reasoning, evidence_quote, severity_assessment}`.
 4. If `verdict == "falsify"`, set the finding's `validation_status = "dismissed_cross_model_falsification"` and copy the codex response into `fp_gate_result`. If `verdict == "confirm"`, pass through unchanged.

package/skills/apt-prototype/LOGIC.md

@@ -1,11 +1,3 @@
-<!--
-Adapted from Matt Pocock's MIT-licensed skill suite:
-https://github.com/mattpocock/skills/blob/main/skills/engineering/prototype/LOGIC.md
-Licensed under MIT. Modifications: scoped to terminal-app prototypes
-that validate state machines, protocols, and control flow. Aligned with
-the 5 universal rules in apt-prototype/SKILL.md.
--->
-
 # LOGIC branch — Terminal app for state-machine validation
 
 When the user's question is about **behavior**, the prototype is a

package/skills/apt-prototype/SKILL.md

@@ -29,7 +29,7 @@ planning artifact, NOT a feature, and NOT something to merge. The output
 is a single-command-runnable prototype that lets the user feel whether
 the question's answer is "yes" or "no", then gets thrown away.
 
-**Pocock adoption attribution.** Discipline ported from Matt Pocock's
+**Aperant adoption attribution.** Discipline ported from 's
 MIT-licensed `prototype` skill. Routes between two branches by
 question-type; the UI branch delegates to Aperant's existing
 `/apt:mockup` skill for HTML+Tailwind variants. The LOGIC branch and
@@ -70,7 +70,7 @@ If the question is genuinely ambiguous, ask ONE clarifying question
 ("are you asking about behavior or appearance?") — do NOT enter a long
 interview.
 
-## The 5 Universal Rules (Pocock discipline, applies to both branches)
+## The 5 Universal Rules (Aperant discipline, applies to both branches)
 
 These five rules apply to EVERY prototype this skill produces. They are
 load-bearing — violating them collapses the prototype into ceremony
@@ -109,7 +109,7 @@ disguised as a question.
 When the question is about behavior / control flow / state machines /
 protocols:
 
-1. Read `LOGIC.md` for the discipline (ported from Pocock's
+1. Read `LOGIC.md` for the discipline (ported from 's
    `prototype/LOGIC.md` with MIT attribution).
 2. Write ONE file (e.g., `prototype.mjs`, `prototype.ts`, or
    `prototype.py`) that:
@@ -126,7 +126,7 @@ protocols:
 
 When the question is about layout / aesthetics / flow / discoverability:
 
-1. Read `UI.md` for the discipline (ported from Pocock's
+1. Read `UI.md` for the discipline (ported from 's
    `prototype/UI.md` with MIT attribution).
 2. Invoke `/apt:mockup --variants 3` as a sub-step. apt:mockup already
    enforces the UI-specific universal rules (zero-dep Tailwind CDN, no

package/skills/apt-prototype/UI.md

@@ -1,11 +1,3 @@
-<!--
-Adapted from Matt Pocock's MIT-licensed skill suite:
-https://github.com/mattpocock/skills/blob/main/skills/engineering/prototype/UI.md
-Licensed under MIT. Modifications: routed through Aperant's existing
-apt:mockup skill rather than a freestanding HTML+Tailwind generator;
-aligned with the 5 universal rules in apt-prototype/SKILL.md.
--->
-
 # UI branch — Delegates to apt:mockup
 
 When the user's question is about **appearance / layout / flow /

package/skills/apt-quick/SKILL.md

@@ -52,7 +52,37 @@ Execute a small task quickly without full pipeline overhead. For small fixes, do
 
 Extract the task description from `$ARGUMENTS`.
 
-Generate a task ID: `quick-{YYYYMMDD}-{short-slug}` (e.g., `quick-20260410-fix-typo`).
+### 1a. Resolve canonical task id (idempotent)
+
+QUICK now produces a canonical state.active_tasks record so `/apt:ship` can find the task via the lite ship profile. The body owns idempotency because `apt-tools task create` does NOT guard against existing ids (see spec §3 R8).
+
+Two invocation paths converge here:
+
+- **Router path** (`/apt` → `/apt:quick`): the router has already called `task create` and injected `task_id` into your skill context.
+- **Direct path** (`/apt:quick foo`): no `task_id` in context — you create one now.
+
+Sequence:
+
+1. **If `task_id` is present in skill context** (router path):
+   ```bash
+   apt-tools task get . --id {task_id}
+   ```
+   - If exit 0 AND the returned record has `track === "QUICK"` → reuse, skip the create call.
+   - Else (record missing OR wrong track) → call:
+     ```bash
+     apt-tools task create . --description "$ARGUMENTS" --track QUICK --id {task_id}
+     ```
+     Parse `task_id` from the returned envelope (it will match the id you passed).
+
+2. **If no `task_id` in skill context** (direct path):
+   ```bash
+   apt-tools task create . --description "$ARGUMENTS" --track QUICK
+   ```
+   Parse the generated `task_id` from the envelope — it will be the canonical `{slug}_YY-MM-DD` shape.
+
+The task id is now canonical (no more `quick-YYYYMMDD-*` invention). `QuickTaskSchema` accepts both the canonical `{slug}_YY-MM-DD` form and the legacy `quick-YYYYMMDD-{slug}` form for back-compat with already-shipped task records on disk.
+
+### 1b. Create QUICK working directory
 
 ```bash
 mkdir -p .aperant/quick/{task-id}