incitaciones 0.3.2 → 0.5.0

package/pi-package/skills/create-issues/references/criteria.md

@@ -12,6 +12,10 @@ Use these criteria to evaluate whether a plan has been translated into strong tr
 | **Actionable Title** | Short, specific, and domain-oriented. Prefer behavior over component names. |
 | **Traceability** | Contains a direct reference to the source plan/spec section or story. |
 | **Verifiability** | Acceptance criteria are binary and observable. |
+| **Quantified Must gate** | Hard acceptance criterion carries a unit and number (Planguage Must), never an adjective. |
+| **Machine-checkable Meter** | An exact runnable command (Meter) whose exit code decides the gate; verifiable at the ticket's `base_commit`. |
+| **Anti-goals** | Negative constraints name prohibited behaviors (test edits, dependency additions, API breaks) so agents can't cheat the gate. |
+| **Baseline anchored** | Measurable claims record the pre-work value and the HEAD SHA as `base_commit` metadata for staleness detection. |
 | **Dependency hygiene** | Only real blockers are encoded; parallel work is not serialized without reason. |
 | **Workflow Mandate** | Includes the mandatory TDD and Tidy First block. |
 | **Execution mode** | Slice is explicitly marked AFK or HITL. |
@@ -23,6 +27,7 @@ Use these checks before publishing:
 - [ ] Does this issue deliver a narrow but complete path through relevant layers?
 - [ ] Could someone demo or verify this slice without waiting for a later ticket?
 - [ ] Is this a user-visible or system-verifiable outcome rather than plumbing-only work?
+- [ ] Could a fresh agent verify the Must gate by running the Meter command verbatim?
 - [ ] If the ticket is preparatory, is that preparatory work itself independently valuable?
 - [ ] Would splitting by backend/frontend/schema create worse horizontal tickets than the current slice?
 

package/pi-package/skills/create-issues/references/templates.md

@@ -31,6 +31,13 @@ Ref: [Link to plan/spec file and section]
 - `path/to/file2`
 - `[subsystem or surface area if exact files are not yet known]`
 
+## Verifiable Value Claim
+
+**Must (hard gate):** [Quantified threshold defining done, with unit and number — e.g. "P95 latency ≤ 250 ms at 100 req/sec"; never "fast" or "robust"]
+**Meter:** [Exact runnable command that verifies the Must gate — e.g. `pytest tests/val_claims/test_issue_NNN.py -q`; exit 0 = pass]
+**Baseline:** [Measured value before work starts — e.g. "P95 = 450 ms"; omit if not measurable]
+**Regression suite:** [Existing tests that must keep passing — e.g. `pytest tests/core/`]
+
 ## Acceptance Criteria
 
 - [ ] [Binary, observable criterion 1]
@@ -47,6 +54,11 @@ Or: `None - can start immediately`
 **CRITICAL: Follow Test Driven Development and Tidy First workflows.**
 - Write tests *before* writing implementation code.
 - Clean up related code *before* adding new functionality.
+
+**Anti-goals (do NOT):**
+- [Prohibited behavior with obvious reward-hacking payoff — e.g. "modify, disable, or delete tests in `tests/core/`"]
+- [e.g. "add new dependencies or modify lockfiles"]
+- [e.g. "break public API / exported interfaces"]
 ```
 
 ## Issue Creation Summary Template
@@ -65,6 +77,7 @@ Or: `None - can start immediately`
 - **Total Issues Created:** [count]
 - **Dependencies Defined:** [count]
 - **Labels Applied:** [e.g., needs-triage]
+- **Base Commit Anchored:** [git SHA recorded in `base_commit` metadata]
 
 ### Created Issues
 1. **[ID] [Title]** - [Link/Reference]

package/pi-package/skills/issue-review/SKILL.md

@@ -34,6 +34,7 @@ Treat the best issue sets as:
 - minimal but sufficient dependency graphs
 - explicit about AFK vs HITL work
 - traceable back to stories, plans, or specs
+- machine-verifiable value claims: quantified Must gate, runnable Meter, explicit anti-goals, and a `base_commit` anchor that reveals staleness
 
 ## Rules
 

package/pi-package/skills/issue-review/references/pass-0-preflight.md

@@ -34,4 +34,38 @@ Recommendation: consider a decomposition ticket to split `<file>` before these
 tickets run (see navari-a3cv pattern). If not decomposing now, add a
 co-modification note to all affected tickets.
 
+**Check 3 — stale base commit (freshness):**
+```bash
+bd list --format json | python3 -c "
+import json, subprocess, sys
+issues = json.load(sys.stdin)
+head = subprocess.run(['git','rev-parse','HEAD'], capture_output=True, text=True).stdout.strip()
+for i in issues:
+    meta = i.get('metadata') or {}
+    base = meta.get('base_commit')
+    if not base or base == head:
+        continue
+    files = meta.get('files') or []
+    changed = []
+    if files:
+        changed = subprocess.run(
+            ['git','diff','--name-only', f'{base}..HEAD', '--'] + files,
+            capture_output=True, text=True).stdout.split()
+    if changed:
+        print(i['id'], 'STALE-TOUCHED', changed)
+    else:
+        print(i['id'], 'BEHIND-HEAD')
+"
+```
+Flag `[PRE-003] HIGH` for STALE-TOUCHED: files in the ticket's scope changed since
+`base_commit` — the description, acceptance criteria, or Meter may no longer apply.
+Flag `[PRE-004] LOW` for BEHIND-HEAD: repo moved but ticket files untouched —
+likely still valid, only re-anchor.
+Fix: re-validate the ticket content against the current tree, then re-anchor:
+```bash
+sha=$(git rev-parse HEAD)
+bd update <id> --metadata "{\"base_commit\": \"$sha\"}"
+```
+Tickets missing `base_commit` entirely: flag as part of PRE-001 remediation.
+
 **Prefix:** PRE-001, PRE-002, etc.

package/pi-package/skills/issue-review/references/pass-5-executability.md

@@ -3,6 +3,7 @@
 Focus on:
 - Can another developer or agent pick this up immediately?
 - Are verification steps concrete and end-to-end?
+- Is there a machine-checkable Must gate (quantified, unit + number) backed by a runnable Meter command?
 - Are priorities and labels sensible?
 - Are HITL handoff points explicit?
 - Is it clear what demo, test, or observable behavior proves completion?
@@ -11,6 +12,10 @@ Watch for:
 - Hidden conversational context
 - "You know what to do"
 - Missing verification commands or test references
+- Qualitative acceptance criteria with no unit or threshold ("fast", "robust", "clean") — a Scale/Meter is missing
+- A Meter command that cannot run at the ticket's `base_commit` (stale claim) or that no fresh agent could execute verbatim
+- Missing anti-goals on tickets touching tests, lockfiles, or public interfaces (reward-hacking surface: nothing stops gaming the gate)
+- No regression suite named (pass-to-pass coverage unspecified)
 - HITL work masquerading as AFK
 - Tickets that cannot be closed without information from another issue not listed as a blocker