haipipe-application-lifecycle

name	haipipe-application-lifecycle
description	Orchestrator for the intervention structure lifecycle (1-lifecycle). Routes to stage specialists across the venue-free/venue-aligned boundary: seed and the evidence ladder (1a-descriptions, 1b-themes, 1c-claims, 1d-advice) are venue-FREE (don't change on retarget); venue pins the modality and gates stages 3-5; pitch, narrative, display, and section-edit are venue-ALIGNED (rewrite on retarget). The `ladder` verb runs 1a->1d as one sweep with venue-scaled gate batching. Stage skills internally run DRAFT -> PROBE -> REVISE -> CHECK via 2-phase/ workers. Trigger: lifecycle, advance, next stage, ladder, intervention structure, /haipipe-application-lifecycle.
argument-hint	[stage-verb|ladder] [intervention-path]
allowed-tools	Bash, Read, Grep, Glob, Skill
metadata	{"version":"0.4.4","last_updated":"2026-07-19","summary":"Routes intervention structural work across the venue-free/venue-aligned boundary: seed + the ladder (1a-1d) are venue-FREE, the venue pin gates stages 3-5, and pitch/narrative/display/section-edit rewrite on retarget. History: ./CHANGELOG.md."}

Skill: haipipe-application-lifecycle (orchestrator)

User-facing entry for intervention structural work -- everything that decides what the intervention is before the artifact exists, or when the argument needs rethinking. The orchestrator owns routing only; each stage specialist owns its own workflow, inputs, and outputs.

The lifecycle has a venue-free / venue-aligned boundary. Seed and the evidence ladder (1a-1d) are venue-FREE (they don't change when you retarget to a different channel). Venue is the decision gate that pins the modality in STATUS.md -- and, because application venues differ in weight, it also writes which stages the venue skips (stages_skipped) and how much of the claims ledger must settle (claims_settlement). Pitch, narrative, display, and section-edit are venue-ALIGNED (they rewrite when you retarget).

/haipipe-application-lifecycle                       -> dashboard (list specialists + pipeline)
/haipipe-application-lifecycle seed <args>           -> 0-lifecycle/0-seed/0-seed.md (venue-FREE)
/haipipe-application-lifecycle ladder <args>         -> the 1a->1d sweep (each rung's skill in order; ONE batched gate per the venue's depth, Stage Gate Protocol)
/haipipe-application-lifecycle descriptions <args>   -> 0-lifecycle/1a-descriptions/1a-descriptions.md (venue-FREE anchored data profile)
/haipipe-application-lifecycle themes <args>         -> 0-lifecycle/1b-themes/1b-themes.md (venue-FREE grounded themes)
/haipipe-application-lifecycle claims <args>         -> 0-lifecycle/1c-claims/1c-claims.md (venue-FREE claim ledger + campaign)
/haipipe-application-lifecycle advice <args>         -> 0-lifecycle/1d-advice/1d-advice.md (venue-FREE design advice -- the ladder's deliverable)
/haipipe-application-lifecycle venue <args>          -> 0-lifecycle/2-venue/2-venue.md (choice + Artifact Principles) + STATUS.md venue pin (venue + stages_skipped + claims_settlement) (decision gate)
/haipipe-application-lifecycle pitch <args>          -> 0-lifecycle/2-pitch/2-pitch.md (venue-ALIGNED goal + theory of change)
/haipipe-application-lifecycle narrative <args>      -> 0-lifecycle/3-narrative/3-narrative.md (venue-gated)
/haipipe-application-lifecycle display <args>        -> 0-lifecycle/4-display/4-display.md (venue-gated; owns per-unit jobs)
/haipipe-application-lifecycle section-edit <args>   -> 0-lifecycle/5-section-edit/{section}/ (sectioned venues only)
/haipipe-application-lifecycle "<natural language>"  -> infer stage, dispatch

Two-Axis Model (stages x phases)

Stage skills are the USER-FACING surface. Internally, each stage skill drives the shared phase cycle DRAFT -> PROBE -> REVISE -> CHECK by dispatching the internal workers in 2-phase/ (haipipe-application-draft, haipipe-application-probe, haipipe-application-revise, haipipe-application-check). CHECK is the only human-involved phase; DRAFT settles content with the user, PROBE and REVISE are agent-only.

This router routes users to STAGE skills only -- never to phase skills. If a request sounds like a phase ("gather evidence for claims", "polish the pitch"), route to the owning stage skill and let it dispatch.

Stage artifacts are markdown (N-<stage>.md + _LOG_ in a stage FOLDER); the questions a stage raises live in the flat pool 1-probes/, keyed back by each section's serves:. Stage gates: ../../haipipe-application/SKILL.md (Stage Gate Protocol section).

Intervention Lifecycle Contract

THE single source of truth for the intervention lifecycle: the folder contract, the stage spine, venue gating, the venue-FREE/ALIGNED boundary, the maturity ladder, and the evidence flow. The application lifecycle is a delivery lifecycle. It owns the intervention-specific story, the stage-1 evidence ladder, content elements, and artifact text. Project-level evidence lives in discoveries and tasks. Same spine ORDER as the paper family with one intentional delta: paper's single 1-claims stage is here the four-rung ladder 1a-1d (../../SOP-ladder-restage.md); the venue profile gates which stages fire.

Folder Contract

<intervention-root>/
├── STATUS.md                 venue, stages_skipped, claims_settlement, current_layer, maturity, Gate Ledger
├── 0-lifecycle/
│   ├── 0-seed/           venue: FREE      0-seed.md + _LOG
│   ├── 1a-descriptions/  venue: FREE      1a-descriptions.md (anchored data summaries + as-of dates) + _LOG
│   ├── 1b-themes/        venue: FREE      1b-themes.md (grounded themes T←D) + _LOG
│   ├── 1c-claims/        venue: FREE      1c-claims.md (Claims/Campaign, C←T + claim STATUS) + _LOG
│   ├── 1d-advice/        venue: FREE      1d-advice.md (design advice A←C — the ladder's deliverable) + _LOG
│   ├── 2-venue/          venue: PIN       2-venue.md (choice + Artifact Principles) + _LOG
│   ├── 2-pitch/          venue: ALIGNED   2-pitch.md + _LOG
│   ├── 3-narrative/      venue: GATED     3-narrative.md + _LOG          (if venue requires)
│   ├── 4-display/        venue: GATED     4-display.md + _LOG            (if venue requires)
│   └── 5-section-edit/   venue: GATED     per-section scaffolds + _LOG   (sectioned venues)
├── 0-sections/               sectioned-venue prose
├── 0-artifacts/              <slug>-v{N}.md · REVIEW-* · CLAIM_AUDIT.md
├── 1-probes/                 the flat probe pool (one file per TOPIC, PPNN_<topic>/)
├── 1-rounds/vYYMMDD/         work rounds
└── data/contract.yaml        input-data contract (data-consuming venues)

Stage docs are markdown + _LOG (argument documents need no compilation). 0- = source of truth, 1- = process.

Lifecycle Stages

Stage	Job	Main question	Venue	Typical handoff
0-seed	Keep the intervention possibility alive	Why might this work?	FREE	ladder (1a) or drop
1a-descriptions	Anchored data profile (the D rung)	What does the data look like, dated?	FREE	themes
1b-themes	Grounded pattern space (the I rung)	Which patterns/topics emerge?	FREE	claims
1c-claims	Claim ledger + evidence campaign (the K rung)	Which claims generalize?	FREE	advice
1d-advice	Design advice (the W rung, the deliverable)	What should the content do, derived from which claims?	FREE	venue → pitch
venue	Pin the output modality	Which channel fits?	(chooser)	writes venue + stages_skipped + claims_settlement
2-pitch	One-minute goal + theory of change	What is this selling, to whom?	ALIGNED	narrative or draft
3-narrative	Structure the output's arc	How do claims compose?	GATED	display
4-display	Content elements + per-unit jobs	What element carries each claim, and what job does each unit do?	GATED	section-edit or draft
5-section-edit	Per-section DPRC on venue-declared sections	Does each section's prose do its job?	GATED	draft
draft	Compose the deliverable (haipipe-application-artifact)	Is the artifact venue+audience-true?	ALIGNED	review
review / claim-audit	Audience fit + claim traceability	Ship it?	--	deploy or loopback

The retired minimap stage's concern (per-unit jobs) lives inside 4-display.

Venue Gating

The venue pin (between the ladder's 1d gate and pitch) writes three STATUS.md rows the whole system reads:

| venue |             sms | push | reminder | checklist | email | dashboard | ui-card | report
| stages_skipped |    which of narrative/display/section-edit this venue skips
| claims_settlement | light | medium | full   (how much of the ledger must settle before draft)

                 narrative   display   section-edit   claims_settlement   gate depth
venue-sms        skip        skip      skip           light               inline
venue-push       skip        skip      skip           light               inline
venue-reminder   skip        skip      skip           light               inline
venue-checklist  optional    skip      skip           medium              inline
venue-email      req         optional  skip           medium              inline
venue-dashboard  req         req       req            full                report
venue-ui-card    req         req       optional       full                report
venue-report     req         req       req            full                report

Authoritative per-venue table: each ../../venue/venue-<name>/README.md. Simple venues: seed → ladder → venue → pitch → draft. Complex venues: all stages before draft. The venue also batches the LADDER's gates (light: one combined gate at 1d; medium: 1c + 1d; full: four) — see the Stage Gate Protocol in ../../haipipe-application/SKILL.md.

Venue-FREE / Venue-ALIGNED Boundary

Seed and the evidence ladder (1a-1d) are venue-FREE: written before the pin, unchanged on retarget (data truth, patterns, claims, and content-level design advice does not change with the channel). Pitch, narrative, display, and section-edit are venue-ALIGNED: they rewrite on retarget. Retargeting (sms → dashboard) re-runs venue + pitch and may DEEPEN the ladder's settlement requirement — it never invalidates it. Slot-mapping (which advice entry fills which template slot) is venue-ALIGNED work and happens in draft/display, never in the ladder.

Phase Dimension

Stages × phases is a two-axis model. Each stage skill in 1-lifecycle/ defines WHAT the stage delivers; the 2-phase/ workers define HOW: DRAFT → PROBE → REVISE → CHECK (haipipe-application-{draft,probe,revise,check}). The PROBE phase runs the probe layer's five-step loop — ORGANIZE → MATCH → DISPATCH → POINT → INTERPRET — through the haipipe-application-probe worker, the ONLY door. DISPATCH goes through the stake-free collector Agent(haipipe-probe-q-executor-agent), which calls the task/discovery orchestrators in clean context; the stage never calls them itself. A probe is COMMUNICATION, not judgment: it carries a question out and an answer back, and a claim's STATUS is written by the author into 1c-claims.md, never in the probe file. PROBE ends with a VERIFY step: check-probe-cards.sh FAILs state: planned sections, dangling refs, harvest: OWED lane debts, and dead vocabulary. The CHECK gate re-runs the same checker (its teeth) and runs checks.sh (markdown-safe deterministic checks); > CHECK: threads are seeded in stage docs only, and artifact-level findings go to the Gate Ledger notes. CHECK is the only human-involved phase, venue-scaled (inline for simple venues, full reports for complex). Users invoke stage skills only, never phases.

Maturity Ladder

Maturity is derived from disk, not declared. Orthogonal to the current stage.

maturity           condition
──────────         ─────────────────────────────────────────────
prospect           0-seed/ exists
data-described     1a-descriptions/ has anchored D entries
claim-ledger       1c-claims/ has C-slots
advised            1d-advice/ has derived A entries (ladder gate passed)
venue-pinned       STATUS.md has venue:
pitched            2-pitch/ gate-approved
narrated           3-narrative/ gate-approved (if venue requires)
display-mapped     4-display/ gate-approved (if venue requires)
section-edit       5-section-edit/ scaffolds with DPRC in progress (sectioned venues)
drafted            0-artifacts/ has >=1 artifact
reviewed           review pass completed
deployed           artifact shipped to channel
iterating          post-deploy round open with A/B results
retired            kill criterion met; no further work

For simple venues, maturity jumps from pitched straight to drafted.

Evidence Flow (flat probe pool)

stage DRAFT raises the questions (a Q-consumer list); APPROVE (human) picks which to pursue
    ↓
① ORGANIZE  each approved question → an ENTRY (## QX<n>) in 1-probes/PPNN_<topic>/ (one file per
            TOPIC), with ### q-executor (stake stripped) / ### q-consumer / ### bank binding / ### a-executor
    ↓
② MATCH     scan the bank's QA corpus FIRST — most sections REUSE an existing answer and stop here
    ↓
③ DISPATCH  only the misses, via Agent(haipipe-probe-q-executor-agent) — the stake-free collector,
            which calls the task/discovery orchestrators in clean context (that context IS the wall)
    ↓
④ POINT     target: → the answering QA FILE (verify with ls + the state line)
    ↓
⑤ INTERPRET copy the QA answer into ### a-executor; each Q-consumer then writes its own a-consumer
            in the stage doc. If it serves a claim, the AUTHOR flips that claim's STATUS
            (supported | weak | GAP) in 1c-claims.md — never in the probe file
    ↓
VERIFY: check-probe-cards.sh — planned entries, dangling refs, and stale vocabulary FAIL;
the stage CHECK gate re-runs the same script before it can go green

Light settlement venues rarely dispatch — they REUSE from the bank's existing QA corpus; full venues run the whole chain. Probe files live in the flat 1-probes/ pool: one file per TOPIC, one ## QX<n> ENTRY per q-executor.

Paper ↔ Application Comparison

paper                                application
─────                                ──────────────
same spine order                     stage 1 differs by design: paper = single 1-claims ledger
                                     (Hypotheses play the theme role; the manuscript's own
                                     Methods/Results carry D/I) — paper delivers K;
                                     application = the 1a-1d evidence ladder — delivers W
venue/ = journal playbooks          venue/ = output modalities (tone-by-audience folded in)
all stages fire; claims fully settle venue gates stages 3-5 + sets settlement depth + batches ladder gates
0-sections/ TeX → compile → submit   0-artifacts/ markdown → draft → review → deploy
respond (rebuttal) / present         iterate (A/B results → refine; backfills 1a, staleness A←C←T←D)
Paper Console                        Intervention Console
papers repo-backed                   interventions = plain in-project folders

Natural Pipeline Order

  VENUE-FREE (don't change on retarget)
  ──────────────────────────────────────
  seed (0)       why this intervention might work (kill criteria, audience hunch)
      ↓
  THE EVIDENCE LADDER (1a-1d, echoes D->I->K->W; `ladder` runs the sweep)
      ↓
  descriptions (1a)   what the data looks like: anchored summaries (statistic + pointer + as-of date)
      ↓
  themes (1b)         what patterns/topics emerge: thematic extraction grounded in D ids + discovery sources
      ↓
  claims (1c)         what generalizes: supported / weak / GAP, theme-tagged, evidence campaign
      ↓
  advice (1d)         what to do: design advice derived from claims -- the ladder's DELIVERABLE
                      venue-neutral throughout; no slot-mapping, no channel framing

  VENUE DECISION
  ──────────────────────────────────────
      ↓
  venue          pin modality in STATUS.md (stages_skipped + claims_settlement); write 2-venue.md (Artifact Principles)
                 (gate between FREE and ALIGNED)

  VENUE-ALIGNED (rewrite on retarget; ° = fires only if the venue requires it)
  ──────────────────────────────────────
      ↓
  pitch (2)      one-minute goal + theory of change for THIS venue + audience
      ↓
  narrative (3)° arc structure from the claim ledger
      ↓
  display (4)°   content elements: what unit carries each claim + each unit's job
                 (the retired minimap concern lives here, per-unit)
      ↓
  section-edit (5)°  per-section DPRC for sectioned venues (report, dashboard spec),
                     syncing prose to 0-sections/

After the lifecycle spine, delivery tooling lives under 3-deliver/ (haipipe-application-artifact = the draft verb, then review, claim-audit, deploy) and 4-iterate/.

Retarget rule: when the venue changes, seed and the ladder stay unchanged (venue-FREE); the new venue may demand deeper claims SETTLEMENT (more GAPs resolved, deeper 1d derivations), which is gate work, not content invalidation. Pitch, narrative, display, and section-edit rewrite for the new venue.

Ladder sweep (ladder verb): dispatch the four rung skills in order (descriptions -> themes -> claims -> advice), each running its own DPRC. Gate batching per the venue's depth (Stage Gate Protocol, ../../haipipe-application/SKILL.md): light = ONE combined inline gate at 1d (one approval writes four ledger rows); medium = combined gate at 1c + gate at 1d; full = four individual gates. A rung that hits a blocker stops the sweep at its own CHECK. Rungs loop internally (multi-round DPRC, loop-until-dry; Stage Gate Protocol → Rounds within a rung) and may back-route mid-phase ([ROUTE -> <rung>] in _LOG); the sweep re-enters the routed-to rung, then resumes order -- the ladder is a flywheel, not a one-way climb (README).

Venue-Gated Dispatch

Before dispatching stages 3-5, read STATUS.md stages_skipped. Dispatching a skipped stage is a routing error: tell the user the pinned venue skips it and offer the frontier instead. Venue examples (authoritative table: each venue/venue-<name>/README.md):

sms / push / reminder    skip narrative, display, section-edit   (claims_settlement: light)
checklist / email        narrative optional; skip section-edit   (claims_settlement: medium)
dashboard / ui-card /    all stages fire                         (claims_settlement: full)
report

Auto-Detect Frontier (no verb given)

1. Read STATUS.md: venue, stages_skipped, Gate Ledger, current_layer.
2. Build the ordered stage list [0-seed, 1a-descriptions, 1b-themes, 1c-claims,
   1d-advice, venue, 2-pitch, 3-narrative, 4-display, 5-section-edit],
   dropping stages in stages_skipped.
3. Frontier = earliest stage without a gate-confirmed artifact
   (disk predicate first, ledger second; drift -> trust disk).
4. If no venue pinned and the ladder (through 1d) is confirmed -> frontier = venue.
5. Dispatch to the frontier's stage skill (an unstarted ladder -> suggest the
   `ladder` sweep); if the lifecycle is complete for this venue -> suggest
   /haipipe-application draft.

Loopback Rule

symptom                                  → loop back to
─────────────────────────────────────────────────────────
data profile stale / number unanchored   → descriptions (1a)
theme ungrounded / pattern space wrong   → themes (1b)
evidence missing for claim               → claims (1c)
advice entry does not follow from its claims → advice (1d)
theory of change wrong                   → pitch
output structure wrong                   → narrative (or venue)
content element doesn't carry its claim  → display
section prose fails its job              → section-edit
venue wrong for audience                 → venue (re-pin; pitch+ re-couple; the ladder SURVIVES)
stakeholder/clinician review rejected    → round → target stage
A/B test shows no effect                 → pitch or claims (1c), with fresh A/B data backfilled into 1a first
kill criterion met                       → seed → STATUS.md retired

Specialist Return Contract

Each stage specialist returns the standard tail (status / summary / artifacts / next) and closes with the full closing block (simplified tail + stage line + phase line) defined in ../../haipipe-application/SKILL.md (Closing Block section); the stage line renders from disk via ../../haipipe-application/stage-strip.sh.

Relation to Parent Orchestrator

haipipe-application (router + Console)  -- consults venue/venue-<name>
            |
            v
haipipe-application-lifecycle (this orchestrator)
  VENUE-FREE:
  |-- seed (0)
  |-- the evidence ladder (`ladder` = the sweep):
  |     |-- descriptions (1a)   anchored data profile
  |     |-- themes (1b)         grounded patterns
  |     |-- claims (1c)         ledger + campaign
  |     +-- advice (1d)         design advice (deliverable)
  VENUE DECISION:
  |-- venue              (pin modality + stages_skipped + claims_settlement in STATUS.md; write 2-venue/2-venue.md Artifact Principles)
  VENUE-ALIGNED (° = venue-gated):
  |-- pitch (2)
  |-- narrative (3)°
  |-- display (4)°       (content elements + per-unit jobs)
  +-- section-edit (5)°  (sectioned venues; per-section hub dispatching 2-phase/ workers)

Every stage skill runs its phases through the shared 2-phase/ workers
(haipipe-application-draft / -probe / -revise / -check); users never invoke those directly.
Delivery tooling (artifact/review/claim-audit/deploy) lives in 3-deliver/; post-deploy in 4-iterate/.

Risk profile

READ-ONLY. Dispatches to stage skills which do the writing.