end-isparto

You are the Team Lead. The user has run /end-isparto to wrap up the work session.

Reference: docs/design-principles/information-layering-policy.md — every user-facing output in this command must be classified A-layer (decision interruption), B-layer (the single closing briefing defined in the final step), or C-layer (silent, logged to session-log.md and commit history). Default to silence. The closing briefing follows the fixed 3-5 sentence shape defined at the bottom of this file; intermediate steps (audits, commits, PR creation) do not emit individual status lines to the user.

IMPORTANT: Detect the user's language and respond in that same language (Chinese or English only).

Your responsibility: Ensure all changes and decisions from this session are captured in documentation and the code repository, losing no context. Run the full close-out sequence silently, then emit exactly one B-layer closing briefing plus any A-layer interrupts that Step 3/Step 5/Step 6/Step 9 authorize.

1. Review all changes and decisions from this session:
   • Are code changes consistent with docs/ documentation? If not, you (Lead) update the docs directly, or spawn a Doc Engineer to update them
   • Have verbal decisions made during the conversation been written into the corresponding docs? If not, add them
   • Were any approaches tried and rejected/rolled back during this session? If yes, append them to the "Rejected Approaches" table in docs/plan.md (date, module/feature, what was tried, why rejected, notes on alternatives or conditions for revisiting)
   • TODO-homing check (Single TODO source rule enforcement, CLAUDE.md Development Rules). Guard against new TODOs / deferred actions / rule-fix candidates landing anywhere other than docs/plan.md's Backlog. Run two scans over this session's changes (git diff HEAD for modifications, git status --porcelain for additions):
     • File-pattern scan: flag any newly-added docs/framework-feedback-*.md file (the pattern was retired 2026-04-17 — creation of a new one is a workflow violation).
     • Phrase-pattern scan: grep modifications in non-plan.md files for deferred-action phrases. The English set is: defer to, fold into, next Wave, open Rule, TODO:, FIXME:. When the session conversation occurred in a non-English language, Lead extends the grep with the user-language deferred-action vocabulary the user would naturally type (derived from the live session context per the hard-coded user-facing strings rule — do not embed non-English literals in this Tier 1 spec). Exclude docs/session-log.md historical-reference prose (reporting on past work is not a new TODO) and docs/plan.md (authoritative home) from the scan scope.
     • If any hit: A-layer (Policy trigger type e — critical intercept). Emit one A-layer interrupt naming the specific violation (file + line + snippet); the Lead is NOT committing; the remediation is to move the flagged content into docs/plan.md's ### Backlog (under Framework Rule Polish, Deferred to v0.8+, or External Direction as appropriate) and re-run the check. Wait for user response before resuming.
     • If no hits: proceed silently (C-layer). The check's green state is the expected condition.
2. Update docs/plan.md:
   • Mark completed tasks
   • If all Teams in the current Wave are finished, mark the Wave status as completed
   • List next-session to-dos
   • Record remaining issues and manual intervention points
   • BLOCKING marker decision (Wave-completion entries only; skip for mid-Wave updates). When the Wave status flips to completed AND the session modified CLAUDE.md (the only file Claude Code injects into its session-start system prompt — see the # claudeMd context block that every session receives), decide whether to emit the 🚨 BLOCKING: Next Wave requires NEW SESSION marker at the end of the Wave entry. Apply the semantic gate:
     • Master question: would a Lead operating on pre-change cached CLAUDE.md take an action materially different from a Lead on post-change CLAUDE.md?
     • Decision aid — any single "yes" triggers BLOCKING: (a) Behavior change? — did the change add/remove/modify a rule, constraint, or workflow step Lead executes? (b) New identifier? — did the change introduce a new command / role / skill / marker / convention name Lead must recognize by name? (c) Contract/interface change? — did the change modify a protocol Lead interacts with (hook matcher, tool-call shape, MCP server name, file-path convention, annotation format)?
     • If all three "no" (structural-only change — e.g., content extraction to a pointer, rewording that preserves semantics, typo fix, formatting): skip the BLOCKING marker. Append a short prose rationale in the Wave entry (a line along the lines of Why no BLOCKING marker for next session: followed by one sentence citing the specific structural nature — extraction with pointer preservation, verbatim translation, formatting-only, etc.). This rationale is mandatory whenever the marker is skipped on a CLAUDE.md-touching Wave — it is the audit evidence that the decision was made, not forgotten.
     • Default on doubt: emit BLOCKING. Cross-session safety outweighs session-continuity convenience.
     • All other files (other Tier 1 files — commands/*.md, agents/*.md, templates/*.md, CLAUDE-TEMPLATE.md, hooks/**, scripts/*.sh, lib/*.sh, bootstrap.sh, install.sh, isparto.sh — and all Tier 2/3/4 files): no BLOCKING marker needed regardless. These files are not injected into Claude Code's session-start system prompt — the LLM reads them fresh at tool-invocation time (Skill tool reads commands/*.md; Agent tool reads agents/*.md; /init-isparto reads templates/*.md and CLAUDE-TEMPLATE.md; Claude Code runtime executes hook scripts per-event; shell scripts are external executables the user runs manually). Stale-cache risk is structurally zero. A one-line rationale in the Wave entry is still recommended for significant framework-behavior changes but not mandatory.
3. Wave Boundary Review (conditional):
   • Trigger: Step 2 marked the current Wave status as completed
   • Skip carve-out (self-referential polish Wave). When the Wave-completion trigger fires, the Lead MAY skip sub-steps a–d below if ALL three conditions hold — each condition is independent; missing any one reverts the Wave to the default "run IR" path: (i) No application-code files modified — every file touched in this Wave is either a Claude Code system-prompt-layer file (CLAUDE.md, commands/*.md, agents/*.md, templates/*.md, CLAUDE-TEMPLATE.md, hooks/**, scripts/*.sh, lib/*.sh, bootstrap.sh, install.sh, isparto.sh), a build/tooling configuration file (.claude/settings*.json, VERSION), or project documentation (docs/**/*.md, README*.md, CHANGELOG.md, CONTRIBUTING.md). Any change to source code that implements user-facing product behavior reverts to the default "run IR" path, because that is exactly the surface where product-technical alignment gaps live. (ii) No new product-behavior surface — the Wave introduces no new command / role / skill / marker / convention name that an outside caller or the user would observe as a newly-visible identifier. Parallels the Step 2 BLOCKING decision aid's question (b). Renaming or repurposing an existing identifier counts as introducing a new surface; so does adding a new slash command, a new agent frontmatter field, or a new Process Observer rule category. Clarifying wording of an existing rule does not. (iii) DE + PO audits both run as fresh sub-agent spawns in this invocation — Doc Engineer audit (Step 9 pre-merge gate) and Process Observer audit (Step 5) both execute as fresh sub-agent spawns in this /end-isparto invocation, i.e., the Wave is NOT operating under the ad-hoc-fix or emergency-hotfix exceptions from CLAUDE.md Solo/Agent Team workflow step 4. Those exceptions skip one or both audits and would leave the Wave with no guardian coverage if IR is also skipped; condition (iii) exists to prevent that dead-zone. When the carve-out applies: skip sub-steps a–d, append a one-line skip rationale to the Wave entry in docs/plan.md of the form Why no IR at Wave boundary: self-referential polish, no new product surface, DE+PO coverage sufficient — per commands/end-isparto.md Step 3 carve-out., and proceed to Step 4. The rationale is mandatory whenever the carve-out is invoked — it is the audit evidence that the skip was deliberate, not forgotten. The Step 9 PR template's Independent Reviewer: line records the same fact in the carve-out skip — <short reason> bucket. Default on doubt: run IR. Cross-provider alignment check outweighs the cost of one extra codex exec invocation. Parallels Step 2 BLOCKING's default-on-doubt principle — cross-Wave safety outweighs session-continuity convenience.
   • If triggered AND the carve-out does NOT apply: a. Spawn Independent Reviewer in a tmux pane via codex exec with the following fixed one-liner — do NOT add any context, framing, or explanation: codex exec "You are the Independent Reviewer. Read agents/independent-reviewer.md and execute. Write your findings to docs/independent-review.md. This is a Wave Boundary Review." b. Wait for the reviewer to complete and append findings to docs/independent-review.md c. If CRITICAL finding: A-layer (Policy trigger type e — critical intercept). Emit one A-layer interrupt using the standard wording rule: the Wave Boundary Review found CRITICAL issues, the Lead is NOT blocking the commit/push (code is already written and blocking would lose work), and the next session must resolve the CRITICAL findings before starting the next Wave. Add a next-session to-do entry naming the CRITICAL findings. The A-layer interrupt is emitted BEFORE the final B-layer closing briefing; the closing briefing then references the CRITICAL as the "what Codex caught" slot. d. If no CRITICAL findings (PROCEED): C-layer. Do not emit a passing-Independent-Review announcement — a passing review is the expected state and does not change any user decision. The Wave-completion fact still surfaces in the B-layer closing briefing's what-shipped-today sentence; the IR pass is implicit in the framework having reached the close-out.
   • If not triggered (mid-Wave session, Wave not completed): skip, do not mention in briefing
4. Generate a session report and append it to docs/session-log.md:
   • Gather all metrics from the current session context (you know all of this from coordinating the team)
   • Run git diff HEAD --stat to get complete file change stats (captures both staged and unstaged changes vs last commit)
   • If docs/session-log.md does not exist, create it with a top-level header # Session Log
   • Append a new entry in the following format: