---
name: proceed-work
description: >
  (What) Execute ONE unit-work — fulfill CONTRACT, record Result, verify inline, retry on FAILURE.
  (When) After /plan-work, or resuming from /check-session. One unit per invocation.
  (Why) Produce verified results. (How) Find PENDING unit → execute → verify → retry if FAILURE → next.
argument-hint: "[WP path or work title]"
metadata:
  author: David Seo of GEM².AI
  version: 15.0.0
allowed-tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
---

(* TPMN SKILL — proceed-work *)

(* === Input === *)
A ≜ [
  project_slug: 𝕊,
  wp_path: Path?,                      (* direct path to WP file, or ⊥ *)
  work_title: 𝕊?,                     (* search term if wp_path not given *)
  unit_index: ℕ?                      (* specific unit to execute, or ⊥ = first PENDING *)
]

(* === Output === *)
B ≜ [
  project_slug: 𝕊,
  wp_path: Path,
  wp_id: 𝕊,
  unit_index: ℕ,                      (* which unit was executed, 1-based *)
  unit_title: 𝕊,
  unit_status: {COMPLETED, ABORTED},  (* this unit's STATUS *)
  unit_state: {SUCCESS, FAILURE}?,    (* this unit's STATE from /verify-work. ⊥ if ABORTED *)
  retried: 𝔹,                        (* true if unit was retried after initial FAILURE *)
  units_done: ℕ,                      (* total completed units in this WP *)
  units_total: ℕ,
  wp_status: {IN_PROGRESS, COMPLETED, ABORTED},  (* derived from all unit statuses *)
  updated_at: 𝕊,                      (* ISO8601 *)
  output_summary: 𝕊                   (* what was accomplished in this unit *)
]

(* === Precondition === *)
P ≜ project_slug ≠ ⊥
    ∧ (wp_path ≠ ⊥ ∨ work_title ≠ ⊥)
    ∧ ".gem-squared/work-plan/" exists

(* === Transform === *)
F ≜ <<
  1. Record started_at timestamp.
     Identify WP:
       IF wp_path provided → read that WP.
       IF only work_title → search work-plan/ for matching WP.
       IF neither → present active/pending works from alarm.md.
  2. Find target unit-work:
       IF unit_index provided → use that unit.
       ELSE → find first unit with STATUS: PENDING in WP file.
       IF no PENDING units remain → wp_status=COMPLETED, output B, STOP.
  3. Ask human permission:
       Show: WP title, target unit title, its CONTRACT (A→B|P), clarity %.
       Show: progress so far (units_done / units_total).
       IF denied → mark unit STATUS: ABORTED, output B, STOP.
  4. Execute the single unit-work:
       Update unit STATUS: PENDING → IN_PROGRESS in WP file.
       Update WP-level STATUS → IN_PROGRESS in WP header.
       Read unit's CONTRACT (A, B, P) → fulfill B given A under P.
       Execution strategy is executor's choice (blackbox).
       On completion:
         Update unit STATUS → COMPLETED, write Result in WP file.
         Refine Tags if implementation diverged from plan:
           add tags for discovered concerns, keep existing valid tags.
           (* Tag format: /^[a-z]+-[a-z]+(-[a-z]+)*$/ — {verb-ing}-{object} *)
  5. Verify the completed unit (inline):
       Invoke /verify-work(wp_path, unit_index=N) — SINGLE mode.
       Read back unit_state from verify-work output.
       IF unit_state = SUCCESS:
         Set retried = ⊥. Proceed to step 6.
       IF unit_state = FAILURE:
         Branch on execution mode:
           INTERACTIVE (human present):
             Report FAILURE with detail from verify-work.
             Ask human: retry (same CONTRACT, different strategy) / skip (accept FAILURE) / abort unit.
             IF retry → clear Result field, re-execute step 4, re-verify. Set retried = ⊤.
             IF skip → accept FAILURE state, set retried = ⊥. Proceed to step 6.
             IF abort → mark unit STATUS: ABORTED, output B, STOP.
           AUTONOMOUS (human said "all units autonomously"):
             Retry once: clear Result field, re-execute step 4 with different strategy, re-verify.
             Set retried = ⊤.
             IF retry succeeds (STATE = SUCCESS) → proceed to step 6.
             IF retry also FAILURE → report to human regardless of mode.
               Human decides: skip / abort / manual intervention.
  6. Finalize:
       Record updated_at timestamp. Output B.
>>

(* === Constraint === *)
CONSTRAINT ≜ [
  ⊢ ONE unit-work per invocation — never batch multiple units,
  ⊢ NEVER proceed without human permission — always ask first,
  ⊢ NEVER write State field directly — invoke /verify-work for all verification,
  ⊢ NEVER archive — that is /archive-work mandate,
  ⊢ NEVER plan or decompose — that is /plan-work mandate,
  ⊢ NEVER modify CONTRACTs — work against what was planned. Retry uses same CONTRACT, different execution strategy,
  ⊢ Execution strategy is executor's blackbox — skill does not dictate how,
  ⊢ Maximum ONE retry per unit — after retry FAILURE, human must decide
]

(* === Invariant === *)
INV ≜ [
  ⊢ Per-unit STATUS in WP file is the source of truth for unit progress,
  ⊢ Unit STATUS transitions: PENDING → IN_PROGRESS → COMPLETED or ABORTED,
  ⊢ Every COMPLETED unit has been verified before proceeding to the next unit,
  ⊢ WP-level STATUS derived: any IN_PROGRESS → IN_PROGRESS, all COMPLETED → COMPLETED,
  ⊢ Result field filled in WP file after each unit completes,
  ⊢ State field written by /verify-work (SINGLE mode) — never by proceed-work directly,
  ⊢ Tags may be refined on completion — add implementation-discovered tags, keep valid plan-time tags,
  ⊢ Human permission required before execution — no silent work,
  ⊢ CONTRACTs are read-only during execution — retry is a new attempt, not a scope change,
  ⊢ WP file is the source of truth
]

(* === Pre-Execution Dialog === *)
Ask_Human ≜ <<
  [field: "confirm",
   prompt: "Proceed with unit-work {N}: {title}? (shows CONTRACT + progress)",
   required: ⊤]
>>

(* === Post-Execution Routing === *)
Routing ≜ [
  wp_status = IN_PROGRESS  → /proceed-work (next PENDING unit),
  wp_status = COMPLETED    → /archive-work (all units verified inline — skip batch /verify-work),
  wp_status = ABORTED      → /archive-work
]