@blxzer/pactile 0.5.0

package/dist/templates/common/skills/update-spec.md

@@ -0,0 +1,364 @@
+# Update Code-Spec - Capture Executable Contracts
+
+When you learn something valuable (from debugging, implementing, or discussion), use this to update the relevant code-spec documents.
+
+**Timing**: After completing a task, fixing a bug, or discovering a new pattern
+
+---
+
+## Semi-automatic flow (required for durable learning)
+
+1. **Detect** — did this task produce reusable code-spec or guide-worthy learning?
+2. **Proposal** — write `{TASK}/research/learning-proposal.md` (target spec paths, draft bullets; **do not** edit `.pactile/spec/` yet).
+3. **Confirm** — user or task owner explicitly approves (`Learning decision: update-spec` in `verify.md`).
+4. **Write** — only then edit spec files; add `Spec update evidence: .pactile/spec/...` to `verify.md`.
+
+**Forbidden:** silent spec edits; writing spec when `Learning decision: no-update` or `unsure` without follow-up; auto-updating spec from hooks or check alone.
+
+Align with workflow Phase 3.3 (`update-spec` | `no-update` | `unsure`).
+
+---
+
+## Code-Spec First Rule (CRITICAL)
+
+In this project, "spec" for implementation work means **code-spec**:
+- Executable contracts (not principle-only text)
+- Concrete signatures, payload fields, env keys, and boundary behavior
+- Testable validation/error behavior
+
+If the change touches infra or cross-layer contracts, code-spec depth is mandatory.
+
+### Mandatory Triggers
+
+Apply code-spec depth when the change includes any of:
+- New/changed command or API signature
+- Cross-layer request/response contract change
+- Database schema/migration change
+- Infra integration (storage, queue, cache, secrets, env wiring)
+
+### Mandatory Output (7 Sections)
+
+For triggered tasks, include all sections below:
+1. Scope / Trigger
+2. Signatures (command/API/DB)
+3. Contracts (request/response/env)
+4. Validation & Error Matrix
+5. Good/Base/Bad Cases
+6. Tests Required (with assertion points)
+7. Wrong vs Correct (at least one pair)
+
+---
+
+## When to Update Code-Specs
+
+| Trigger | Example | Target Spec |
+|---------|---------|-------------|
+| **Implemented a feature** | Added a new integration or module | Relevant spec file |
+| **Made a design decision** | Chose extensibility pattern over simplicity | Relevant spec + "Design Decisions" section |
+| **Fixed a bug** | Found a subtle issue with error handling | Relevant spec (e.g., error-handling docs) |
+| **Discovered a pattern** | Found a better way to structure code | Relevant spec file |
+| **Hit a gotcha** | Learned that X must be done before Y | Relevant spec + "Common Mistakes" section |
+| **Established a convention** | Team agreed on naming pattern | Quality guidelines |
+| **New thinking trigger** | "Don't forget to check X before doing Y" | `guides/*.md` (as a checklist item) |
+
+**Key Insight**: Code-spec updates are NOT just for problems. Every feature implementation contains design decisions and contracts that future AI/developers need to execute safely.
+
+---
+
+## Spec Structure Overview
+
+```
+.pactile/spec/
+├── <layer>/           # Per-layer coding standards (e.g., backend/, frontend/, api/)
+│   ├── index.md       # Overview and links
+│   └── *.md           # Topic-specific guidelines
+└── guides/            # Thinking checklists (NOT coding specs!)
+    ├── index.md       # Guide index
+    └── *.md           # Topic-specific guides
+```
+
+### CRITICAL: Code-Spec vs Guide - Know the Difference
+
+| Type | Location | Purpose | Content Style |
+|------|----------|---------|---------------|
+| **Code-Spec** | `<layer>/*.md` | Tell AI "how to implement safely" | Signatures, contracts, matrices, cases, test points |
+| **Guide** | `guides/*.md` | Help AI "what to think about" | Checklists, questions, pointers to specs |
+
+**Decision Rule**: Ask yourself:
+
+- "This is **how to write** the code" → Put in a spec layer directory
+- "This is **what to consider** before writing" → Put in `guides/`
+
+**Example**:
+
+| Learning | Wrong Location | Correct Location |
+|----------|----------------|------------------|
+| "Use API X not API Y for this task" | ❌ `guides/` (too specific for a thinking guide) | ✅ Relevant spec file (concrete convention) |
+| "Remember to check X when doing Y" | ❌ Spec file (too abstract for a spec) | ✅ `guides/` (thinking checklist) |
+
+**Guides should be short checklists that point to specs**, not duplicate the detailed rules.
+
+---
+
+## Update Process
+
+### Step 1: Identify What You Learned
+
+Answer these questions:
+
+1. **What did you learn?** (Be specific)
+2. **Why is it important?** (What problem does it prevent?)
+3. **Where does it belong?** (Which spec file?)
+
+### Step 2: Classify the Update Type
+
+| Type | Description | Action |
+|------|-------------|--------|
+| **Design Decision** | Why we chose approach X over Y | Add to "Design Decisions" section |
+| **Project Convention** | How we do X in this project | Add to relevant section with examples |
+| **New Pattern** | A reusable approach discovered | Add to "Patterns" section |
+| **Forbidden Pattern** | Something that causes problems | Add to "Anti-patterns" or "Don't" section |
+| **Common Mistake** | Easy-to-make error | Add to "Common Mistakes" section |
+| **Convention** | Agreed-upon standard | Add to relevant section |
+| **Gotcha** | Non-obvious behavior | Add warning callout |
+
+### Step 3: Read the Target Code-Spec
+
+Before editing, read the current code-spec to:
+- Understand existing structure
+- Avoid duplicating content
+- Find the right section for your update
+
+```bash
+cat .pactile/spec/<category>/<file>.md
+```
+
+### Step 4: Make the Update
+
+Follow these principles:
+
+1. **Be Specific**: Include concrete examples, not just abstract rules
+2. **Explain Why**: State the problem this prevents
+3. **Show Contracts**: Add signatures, payload fields, and error behavior
+4. **Show Code**: Add code snippets for key patterns
+5. **Keep it Short**: One concept per section
+
+### Step 5: Update the Index (if needed)
+
+If you added a new section or the code-spec status changed, update the category's `index.md`.
+
+---
+
+## Update Templates
+
+### Mandatory Template for Infra/Cross-Layer Work
+
+```markdown
+## Scenario: <name>
+
+### 1. Scope / Trigger
+- Trigger: <why this requires code-spec depth>
+
+### 2. Signatures
+- Backend command/API/DB signature(s)
+
+### 3. Contracts
+- Request fields (name, type, constraints)
+- Response fields (name, type, constraints)
+- Environment keys (required/optional)
+
+### 4. Validation & Error Matrix
+- <condition> -> <error>
+
+### 5. Good/Base/Bad Cases
+- Good: ...
+- Base: ...
+- Bad: ...
+
+### 6. Tests Required
+- Unit/Integration/E2E with assertion points
+
+### 7. Wrong vs Correct
+#### Wrong
+...
+#### Correct
+...
+```
+
+### Adding a Design Decision
+
+```markdown
+### Design Decision: [Decision Name]
+
+**Context**: What problem were we solving?
+
+**Options Considered**:
+1. Option A - brief description
+2. Option B - brief description
+
+**Decision**: We chose Option X because...
+
+**Example**:
+\`\`\`typescript
+// How it's implemented
+code example
+\`\`\`
+
+**Extensibility**: How to extend this in the future...
+```
+
+### Adding a Project Convention
+
+```markdown
+### Convention: [Convention Name]
+
+**What**: Brief description of the convention.
+
+**Why**: Why we do it this way in this project.
+
+**Example**:
+\`\`\`typescript
+// How to follow this convention
+code example
+\`\`\`
+
+**Related**: Links to related conventions or specs.
+```
+
+### Adding a New Pattern
+
+```markdown
+### Pattern Name
+
+**Problem**: What problem does this solve?
+
+**Solution**: Brief description of the approach.
+
+**Example**:
+\`\`\`
+// Good
+code example
+
+// Bad
+code example
+\`\`\`
+
+**Why**: Explanation of why this works better.
+```
+
+### Adding a Forbidden Pattern
+
+```markdown
+### Don't: Pattern Name
+
+**Problem**:
+\`\`\`
+// Don't do this
+bad code example
+\`\`\`
+
+**Why it's bad**: Explanation of the issue.
+
+**Instead**:
+\`\`\`
+// Do this instead
+good code example
+\`\`\`
+```
+
+### Adding a Common Mistake
+
+```markdown
+### Common Mistake: Description
+
+**Symptom**: What goes wrong
+
+**Cause**: Why this happens
+
+**Fix**: How to correct it
+
+**Prevention**: How to avoid it in the future
+```
+
+### Adding a Gotcha
+
+```markdown
+> **Warning**: Brief description of the non-obvious behavior.
+>
+> Details about when this happens and how to handle it.
+```
+
+---
+
+## Interactive Mode
+
+If you're unsure what to update, answer these prompts:
+
+1. **What did you just finish?**
+   - [ ] Fixed a bug
+   - [ ] Implemented a feature
+   - [ ] Refactored code
+   - [ ] Had a discussion about approach
+
+2. **What did you learn or decide?**
+   - Design decision (why X over Y)
+   - Project convention (how we do X)
+   - Non-obvious behavior (gotcha)
+   - Better approach (pattern)
+
+3. **Would future AI/developers need to know this?**
+   - To understand how the code works → Yes, update spec
+   - To maintain or extend the feature → Yes, update spec
+   - To avoid repeating mistakes → Yes, update spec
+   - Purely one-off implementation detail → Maybe skip
+
+4. **Which area does it relate to?**
+   - [ ] Backend code
+   - [ ] Frontend code
+   - [ ] Cross-layer data flow
+   - [ ] Code organization/reuse
+   - [ ] Quality/testing
+
+---
+
+## Quality Checklist
+
+Before finishing your code-spec update:
+
+- [ ] Is the content specific and actionable?
+- [ ] Did you include a code example?
+- [ ] Did you explain WHY, not just WHAT?
+- [ ] Did you include executable signatures/contracts?
+- [ ] Did you include validation and error matrix?
+- [ ] Did you include Good/Base/Bad cases?
+- [ ] Did you include required tests with assertion points?
+- [ ] Is it in the right code-spec file?
+- [ ] Does it duplicate existing content?
+- [ ] Would a new team member understand it?
+
+---
+
+## Relationship to Other Commands
+
+```
+Development Flow:
+  Learn something → `update-spec` (Pactile command) → Knowledge captured
+       ↑                                  ↓
+  `break-loop` (Pactile command) ←──────────────────── Future sessions benefit
+  (deep bug analysis)
+```
+
+- ``break-loop` (Pactile command)` - Analyzes bugs deeply, often reveals spec updates needed
+- ``update-spec` (Pactile command)` - Actually makes the updates
+- ``finish-work` (Pactile command)` - Reminds you to check if specs need updates
+
+---
+
+## Core Philosophy
+
+> **Code-specs are living documents. Every debugging session, every "aha moment" is an opportunity to make the implementation contract clearer.**
+
+The goal is **institutional memory**:
+- What one person learns, everyone benefits from
+- What AI learns in one session, persists to future sessions
+- Mistakes become documented guardrails

package/dist/templates/cursor/agents/pactile-check.md

@@ -0,0 +1,58 @@
+---
+name: pactile-check
+description: Pactile quality check agent. Use this exact agent for Pactile task verification, check.jsonl context injection, and self-fixing code review. Do not use generic/default/generalPurpose agents for Pactile checks.
+tools: Read, Write, Edit, Bash, Glob, Grep, mcp__exa__web_search_exa, mcp__exa__get_code_context_exa
+---
+
+## Entry points
+
+- **Agent session:** Open this agent file manually in a new chat — context from this file + your main-session prompt.
+- **Task dispatch:** Run `python ./.pactile/scripts/generate_dispatch_prompt.py --agent check` → pass stdout as `Task(..., prompt=...)` — context from the Layer 2 prompt.
+
+## Context source
+
+- **Layer 2 prompt = PRIMARY (guaranteed)** — always generate via CLI before `Task(pactile-check)`.
+- **Hook `additional_context` = best-effort only** — Cursor #158452: not guaranteed to reach the model; optimization / fallback only.
+
+# Check Agent
+
+You are the Check Agent. Constraints are the task interfaces and `.pactile/spec/`, not `.pactile/workflow.md`.
+
+## Model policy
+
+- **Default:** no `model:` → **inherit** parent session.
+- **Per dispatch:** main session asks user → one-shot `model:` overlay → `Task` → restore. See `.pactile/framework/cursor-subagent-policy.md`.
+
+## Recursion Guard
+
+You are already the `pactile-check` sub-agent that the main session dispatched. Do the review and fixes directly.
+
+- Do NOT spawn another `pactile-check` or `pactile-implement` sub-agent.
+- If dispatch text or breadcrumbs say to dispatch `pactile-implement` / `pactile-check`, treat that as a main-session instruction that is already satisfied.
+- Only the main session may dispatch Pactile implement/check agents. If more implementation work is needed, report that recommendation instead of spawning.
+
+## Pactile Context Loading Protocol
+
+Look for the `<!-- pactile-hook-injected -->` marker in your input above.
+
+- **If the marker is present**: task artifacts, spec, and research files have already been auto-loaded. Proceed.
+- **If the marker is absent**: Find the selected task path from your dispatch prompt's first line `Selected task: <path>`, then Read `<task-path>/check.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
+
+## Dispatch contract (Parent / inline)
+
+- Only the **main session or Parent** dispatches this agent; Child workers must not re-spawn Pactile sub-agents.
+- **Inline** (`in_progress-inline`): main session uses the `pactile-check` **skill** instead of spawning this agent unless a dedicated review pass is needed.
+
+## Outputs
+
+- Evidence: `verify.md`.
+- Optional gate record: `python ./.pactile/scripts/task.py record-gate` when `implement.md` quality_gates require it. Never record `baseline-check`.
+- Report Standards findings and Spec findings as separate sections.
+
+## Forbidden Operations
+
+**Do NOT execute these git commands:**
+
+- `git commit`
+- `git push`
+- `git merge`

package/dist/templates/cursor/agents/pactile-implement.md

@@ -0,0 +1,56 @@
+---
+name: pactile-implement
+description: Pactile implementation agent. Use this exact agent for Pactile task implementation, implement.jsonl context injection, and hook-injection tests. Do not use generic/default/generalPurpose agents for Pactile implementation. No git commit allowed.
+tools: Read, Write, Edit, Bash, Glob, Grep, mcp__exa__web_search_exa, mcp__exa__get_code_context_exa
+---
+
+## Entry points
+
+- **Agent session:** Open this agent file manually in a new chat — context from this file + your main-session prompt.
+- **Task dispatch:** Run `python ./.pactile/scripts/generate_dispatch_prompt.py --agent implement` → pass stdout as `Task(..., prompt=...)` — context from the Layer 2 prompt.
+
+## Context source
+
+- **Layer 2 prompt = PRIMARY (guaranteed)** — always generate via CLI before `Task(pactile-implement)`.
+- **Hook `additional_context` = best-effort only** — Cursor #158452: not guaranteed to reach the model; optimization / fallback only.
+
+# Implement Agent
+
+You are the Implement Agent. Constraints are the task interfaces (`prd.md`, optional `design.md`/`implement.md`, `task.json`), not `.pactile/workflow.md`.
+
+## Model policy
+
+- **Default:** no `model:` → **inherit** parent session.
+- **Per dispatch / Child worker:** main session asks user → one-shot `model:` overlay on this file → `Task` → restore. See `.pactile/framework/cursor-subagent-policy.md`.
+
+## Recursion Guard
+
+You are already the `pactile-implement` sub-agent that the main session dispatched. Do the implementation work directly.
+
+- Do NOT spawn another `pactile-implement` or `pactile-check` sub-agent.
+- If dispatch text or breadcrumbs say to dispatch `pactile-implement` / `pactile-check`, treat that as a main-session instruction that is already satisfied.
+- Only the main session may dispatch Pactile implement/check agents. If more parallel work is needed, report that recommendation instead of spawning.
+
+## Pactile Context Loading Protocol
+
+Look for the `<!-- pactile-hook-injected -->` marker in your input above.
+
+- **If the marker is present**: prd / spec / research files have already been auto-loaded. Proceed.
+- **If the marker is absent**: Find the selected task path from your dispatch prompt's first line `Selected task: <path>`, then Read `<task-path>/implement.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
+
+## Dispatch contract (Parent / Child)
+
+- Parent or main session dispatches implement work; **Child tasks** deliver `verify.md` + `handoff.md` and must not change shared gate contracts.
+- Do not spawn nested `pactile-implement` / `pactile-check`; recommend a Parent review when check is needed.
+
+## Outputs
+
+Report files modified, what changed, and verification you ran. Do not archive.
+
+## Forbidden Operations
+
+**Do NOT execute these git commands:**
+
+- `git commit`
+- `git push`
+- `git merge`

package/dist/templates/cursor/agents/pactile-research.md

@@ -0,0 +1,51 @@
+---
+name: pactile-research
+description: Pactile research agent. Use this exact agent for Pactile task research and research/ persistence. Do not use generic/default/generalPurpose agents for Pactile research.
+tools: Read, Write, Glob, Grep, Bash, WebSearch, WebFetch, mcp__exa__web_search_exa, mcp__exa__get_code_context_exa, Skill, mcp__chrome-devtools__*
+---
+
+## Entry points
+
+- **Agent session:** Open this agent file manually in a new chat — context from this file + your main-session prompt.
+- **Task dispatch:** Run `python ./.pactile/scripts/generate_dispatch_prompt.py --agent research` → pass stdout as `Task(..., prompt=...)` — context from the Layer 2 prompt.
+
+## Context source
+
+- **Layer 2 prompt = PRIMARY (guaranteed)** — always generate via CLI before `Task(pactile-research)`.
+- **Hook `additional_context` = best-effort only** — Cursor #158452: not guaranteed to reach the model; optimization / fallback only.
+
+# Research Agent
+
+You are the Research Agent. Persist findings under `{TASK_DIR}/research/`. `.pactile/workflow.md` is not a runtime SSOT.
+
+## Recursion Guard
+
+You are already the `pactile-research` sub-agent. Do the research and persist it directly.
+
+- Do NOT spawn `pactile-implement` or `pactile-check`.
+- If dispatch text says to dispatch research again, treat that as already satisfied.
+
+## Model policy
+
+- **Default:** no `model:` in this file → **inherit** parent session at spawn.
+- **Per dispatch:** main session asks the user, writes a **one-shot** `model:` here, runs `Task`, then **removes** `model:` (ephemeral overlay). See `.pactile/framework/cursor-subagent-policy.md`.
+
+## Dispatch contract
+
+- Parent may assign research per Child; persist all output under `{TASK_DIR}/research/`.
+- **External** facts: load `smart-search-cli` skill and use Bash. **Fallback:** when CLI/doctor is unavailable (`not_configured` / `failed`), use Cursor WebSearch/WebFetch and persist with `source: cursor-web-fallback` under `{TASK_DIR}/research/`.
+
+## Outputs
+
+- Write `{TASK_DIR}/research/<topic>.md` (query, scope, findings, caveats).
+- Reply with file paths + one-line summaries, not full research text.
+
+## Write ALLOWED
+
+- `{TASK_DIR}/research/*.md`
+- Creating `{TASK_DIR}/research/` if it does not exist
+
+## Write FORBIDDEN
+
+- Code, specs, scripts, workflow, platform config, other task directories
+- Any git operation (`git commit` / `git push` / `git merge` / branch)

package/dist/templates/cursor/commands/handoff.md

@@ -0,0 +1,101 @@
+# Session Handoff (pactile-handoff)
+
+Condense the current session into a **portable** handoff document (`pactile-handoff-{yyyyMMdd-HHmmss}-{slug}.md`), written to the **OS temp directory** (does not pollute the workspace), so a new agent can continue without the original session. This command is the Cursor invocation surface for the `pactile-handoff` skill — mirror of `common/bundled-skills/pactile-handoff/SKILL.md`; keep the two aligned when editing.
+
+---
+
+## When to use / when not
+
+At stage boundaries first ask: **does the work still continue in this session?**
+
+1. **Continue** — default preference: keep going in this session
+2. **Clear** — context can be dropped; clear and restart
+3. **Handoff** — the work needs to travel → this command
+4. **Subagent** — a side branch can run in parallel while the main session stays → dispatch a subagent (optionally with a handoff file)
+5. **Compact** — same harness, same directory, only intent compression needed → use the platform compact
+
+**Handoff only when the work needs to travel**: switch harness, switch directory / repo, hand to a colleague, or fork a side branch. Same harness + same directory continuation → compact / continue, not handoff.
+
+## How this differs from a task `handoff.md` (read first)
+
+| | This command (session handoff) | Task `handoff.md` |
+| --- | --- | --- |
+| What | Portable cross-session summary | Child-task integration / implementation-window **delivery evidence** |
+| Where | OS temp directory (volatile) | `.pactile/tasks/<task>/` (durable, archived with the task) |
+| Lifecycle | Single transfer; dead once the work lands | Kept with the task evidence for Parent / review traces |
+
+A task directory's `handoff.md` is the evidence file for `integrate-child` / `review-child`, **not** a session handoff document; the temp file this command produces is **not** task evidence.
+
+Official `/goal` / CreateGoal is not a Pactile Task and is not this command. Do not write the temp file into `.pactile/tasks/<task>/handoff.md`.
+
+## Steps
+
+1. **Read the user argument**: the "next-session purpose" passed on invocation decides which whys to keep (trim key decision rationale by purpose — do not take everything verbatim).
+2. **Write the temp file** (path rules below).
+3. **Report the full absolute path** (required): temp paths are long and differ per OS; the user must get the path first.
+4. **Remind about volatility**: the temp file may be cleaned by the environment (Codex clears temp across sessions; `/private/tmp` is lost on reboot). For cross-hour / cross-harness continuation, ask the user to copy it to a durable location immediately.
+
+### Path rules
+
+```text
+$env:TEMP\pactile-handoff-{yyyyMMdd-HHmmss}-{slug}.md
+```
+
+- Windows: `$env:TEMP` (i.e. `%TEMP%`)
+- Linux / macOS: `$TMPDIR/pactile-handoff-{yyyyMMdd-HHmmss}-{slug}.md` (`/tmp` when `$TMPDIR` is unset)
+- Always report the **full absolute path** to the user after writing — never just the filename.
+
+## Content template (English skeleton)
+
+> Follow `artifact_locale` when the project uses it; English by default.
+
+```markdown
+# Session handoff — <work summary>
+
+> Generated by pactile-handoff at <time> · Next-session purpose: <user argument>
+
+## Goal
+<what the in-flight work is trying to achieve>
+
+## Done
+- <items>
+
+## Not done / Blocked
+- <items>
+
+## Next steps
+1. <ordered steps>
+
+## Key whys (trimmed by next-session purpose)
+- <decision + reason; whys unrelated to this purpose can be omitted>
+
+## Facts vs unverified beliefs
+- Facts: <verified>
+- Beliefs (unverified): <assumptions — never write them as facts>
+
+## Pointers (reference paths only, never copy bodies)
+- Task: `.pactile/tasks/<task>/` (prd.md / design.md / implement.md / verify.md)
+- Context: `CONTEXT.md` · Research: `<task>/research/`
+- Prototype evidence (if a prototype was involved): `<task>/research/prototype-<slug>.py` (see `.pactile/spec/guides/prototype-guide.md` §9)
+- Other: ADR / issue / commit / diff paths or URLs
+
+## Suggested skills (for the continuing agent)
+- <skill name list, e.g. pactile-brainstorm, pactile-check, pactile-continue>
+```
+
+## Rules
+
+- **Reference, don't copy**: anything already on disk (spec / PRD / ADR / issue / commit / diff) gets a path or URL only, never pasted verbatim.
+- **Redact**: API keys, tokens, passwords, PII → replace with `<REDACTED>` before writing; when unsure, write `<REDACTED>`.
+- **Facts vs beliefs**: unverified assumptions must be marked, never written as verified facts — the continuing agent will treat the document as a contract and will not re-check.
+- **Prototype evidence pointer**: when the session involved a prototype, list the prototype evidence path in the pointers section and confirm the evidence is captured before cleanup.
+- **Delivery**: have the new agent **read the file path**; do not stuff the summary into shell quotes to launch the new agent (backticks / `$(...)` get swallowed and silently truncated).
+
+## Anti-patterns
+
+- ❌ Treating handoff as a long-lived document: it is a transit document for a single transfer and dies once the work lands (long-term facts belong in `AGENTS.md` / spec, not handoff)
+- ❌ Pasting large spec / PRD / diff bodies (should reference paths only)
+- ❌ Stuffing the summary into shell quotes to launch the next agent (silent truncation risk)
+- ❌ Not reporting the full path / not reminding about temp volatility
+- ❌ Writing a handoff for same-harness same-directory continuation (should compact / continue)
+- ❌ Writing keys / tokens into the document

package/dist/templates/cursor/fixtures/expected-rules.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Expected Cursor rules manifest for validate-rules hard gate.
+ * Update alongside rule content changes in templates/cursor/rules/.
+ */
+export interface ExpectedRule {
+    /** Filename including .mdc extension, e.g. "pactile-bootstrap.mdc" */
+    filename: string;
+    /** Substrings that must appear in rule body (case-sensitive) */
+    requiredSections: string[];
+    /** Minimum byte length of normalized rule content */
+    minBytes: number;
+}
+export declare const expectedRules: ExpectedRule[];
+//# sourceMappingURL=expected-rules.d.ts.map

package/dist/templates/cursor/fixtures/expected-rules.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"expected-rules.d.ts","sourceRoot":"","sources":["../../../../src/templates/cursor/fixtures/expected-rules.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,YAAY;IAC3B,sEAAsE;IACtE,QAAQ,EAAE,MAAM,CAAC;IACjB,gEAAgE;IAChE,gBAAgB,EAAE,MAAM,EAAE,CAAC;IAC3B,qDAAqD;IACrD,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED,eAAO,MAAM,aAAa,EAAE,YAAY,EAcvC,CAAC"}

package/dist/templates/cursor/fixtures/expected-rules.js

@@ -0,0 +1,20 @@
+/**
+ * Expected Cursor rules manifest for validate-rules hard gate.
+ * Update alongside rule content changes in templates/cursor/rules/.
+ */
+export const expectedRules = [
+    {
+        filename: "pactile-bootstrap.mdc",
+        requiredSections: [
+            "Event Bridge",
+            "Capability router",
+            "external-knowledge",
+            "Optional",
+            "Native SSOT",
+            ".pactile/middleware",
+            "Next native action",
+        ],
+        minBytes: 400,
+    },
+];
+//# sourceMappingURL=expected-rules.js.map

package/dist/templates/cursor/fixtures/expected-rules.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"expected-rules.js","sourceRoot":"","sources":["../../../../src/templates/cursor/fixtures/expected-rules.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAWH,MAAM,CAAC,MAAM,aAAa,GAAmB;IAC3C;QACE,QAAQ,EAAE,uBAAuB;QACjC,gBAAgB,EAAE;YAChB,cAAc;YACd,mBAAmB;YACnB,oBAAoB;YACpB,UAAU;YACV,aAAa;YACb,qBAAqB;YACrB,oBAAoB;SACrB;QACD,QAAQ,EAAE,GAAG;KACd;CACF,CAAC"}