gse-compound

name	gse-compound
description	Capitalize learnings across 3 axes. Triggered by /gse:compound at end of sprint.

GSE-One Compound — Capitalization

Arguments: $ARGUMENTS

Options

Flag / Sub-command	Description
(no args)	Run full capitalization across all 3 axes
--axis project	Capitalize project learnings only (Axe 1)
--axis methodology	Capitalize methodology feedback only (Axe 2)
--axis competencies	Capitalize competency notes only (Axe 3)
--learn	Proactively propose LEARN items for the user
--help	Show this command's usage summary

Vocabulary note (Meta-2). "Axe 1/2/3" (capitalized) is deliberate corpus-wide vocabulary naming the three capitalization axes (project learnings / methodology feedback / competencies) — distinct from the coach's 8 monitoring "axes" (lowercase English). The two systems are never interchangeable; do not "translate" one into the other. Convention documented in CLAUDE.md > Activity path reference conventions area.

Prerequisites

Before executing, read:

1. .gse/status.yaml — current sprint and lifecycle state
2. .gse/config.yaml — project configuration
3. .gse/backlog.yaml — completed sprint tasks and their history
4. .gse/profile.yaml — user profile, competency map, learning notes
5. docs/sprints/sprint-{NN}/review.md — review findings for the sprint
6. docs/sprints/sprint-{NN}/release.md — release notes (if delivery occurred)
7. docs/sprints/sprint-{NN}/plan-summary.md — sprint plan archive (generated by DELIVER from .gse/plan.yaml)

Execution Model

COMPOUND is an isolated activity — the orchestrator delegates it to a sub-agent with a fresh context (see Context Architecture in the orchestrator). By the end of a sprint, the main conversation context is heavily loaded with PRODUCE/REVIEW/FIX history. COMPOUND needs a clean context to analyze sprint artefacts objectively.

Before delegation, the orchestrator:

1. Saves a mini-checkpoint (.gse/checkpoints/pre-compound-{timestamp}.yaml)
2. Spawns a sub-agent with: this SKILL.md, state files, all sprint artefacts (review.md, release.md, backlog), and the user profile

After delegation, the orchestrator reads compound.md and displays the capitalization summary to the user.

Workflow

Step 1 — Axe 1: Project Capitalization

Analyze the sprint for project-level learnings:

1. Patterns discovered — Identify recurring code patterns, architectural decisions, or conventions that emerged during the sprint. Record as reusable patterns.

2. Errors and anti-patterns — Extract lessons from review findings (especially HIGH severity), failed tests, and fix cycles. Document what went wrong and how to prevent recurrence.

3. Process deviation scan — Read docs/sprints/sprint-{NN}/review.md for findings tagged as process or methodology deviations (e.g., missing branches, missing test reports, skipped steps), AND read docs/sprints/sprint-{NN}/plan-summary.md for scope changes, skipped activities, and coherence alerts — these are complementary inputs for process deviation analysis. For each deviation (from either source), create an explicit lesson in the Lessons Learned section of compound.md with: what the methodology expected, what actually happened, and the corrective action for future sprints. This ensures process issues are never silently ignored — they become documented, reusable lessons.

4. Best practices confirmed — Identify practices that worked well (clean test coverage, good naming, effective decomposition). Reinforce these as project conventions.

5. Technical debt identified — Flag shortcuts taken during the sprint that should be addressed in future sprints. Add to backlog pool with artefact_type: refactor.

6. Persist to docs/sprints/sprint-{NN}/compound.md — fill the Axe 1: Project Capitalization section of the authoritative template plugin/templates/sprint/compound.md (subsections: What Went Well / What Could Be Improved / Patterns Discovered / Best Practices Confirmed / Learning Notes Generated / Technical Debt). Do not invent an ad-hoc skeleton — the template is the single authority for structure.

Step 2 — Axe 2: Methodology Capitalization

Analyze what worked and what did not in the GSE-One methodology itself during this sprint, then route the observations through a closure Gate.

2.0 — Coach invocation (cross-sprint workflow analysis)

At the start of Axe 2, the orchestrator invokes the coach agent with moment: /gse:compound Axe 2 feed (per coach.md Invocation contract, design §5.17). The coach activates axes 2–8 to produce cross-sprint trend analysis — comparing this sprint's signals against the persistent workflow_observations[] history (see design §5.17 — trend axes quality_trends, sprint_velocity, sustainability each require ≥ 3 sprints of history). Typical coach outputs at this moment:

• sprint_velocity — stability of complexity points delivered per sprint
• quality_trends — evolution of test pass rate, review findings, regression flags
• workflow_health — patterns of skipped activities, non-standard sequences
• process_deviation — recurring DEC- methodology-deviation entries

Coach advice messages (bounded by config.yaml → coach.max_advice_per_check, default 3) are collected and merged with the static sources listed in Step 2.1 below. If nothing meaningful surfaces, this step is silent.

2.1 — Gather observations from the sprint

Sources to scan (in order):

Source	What to extract
docs/sprints/sprint-{NN}/review.md	Findings tagged [METHOD-FEEDBACK] (process-level, not product-level)
.gse/decisions.md (project-wide, per spec §11 — Decision Journal)	DEC- entries where type: methodology-deviation AND sprint == current_sprint (filter on the sprint: field of each entry — see plugin/templates/decisions.md for the canonical format)
.gse/status.yaml → activity_history[*].notes	Free-text notes describing methodology friction
.gse/status.yaml → workflow_observations[] (current sprint, not yet summarized)	Raw observations produced by the coach sub-agent during the sprint across the 7 workflow axes (sprint_velocity, workflow_health, quality_trends, engagement_pattern, process_deviation, sustainability, profile_calibration). Filter: entries where sprint == current_sprint AND summarized != true.
Agent conversation memory for this sprint	Recurring user questions, explicit frustrations, ad-hoc deviations, Gates that felt awkward, Inform notes that surprised the user
docs/sprints/sprint-{NN}/plan-summary.md → ## Outcome Metrics (last ≤ 3 sprints)	Sprint outcome data for the calibration falsifiability review below

For each observation, the agent records:

• Raw text of the observation (verbatim user quote if available)
• Source reference (RVW-NNN, DEC-NNN, activity name, or "conversation")
• Suggested theme label (e.g., "scope-lock ergonomy", "dashboard freshness", "git identity setup")
• Severity heuristic (HIGH = blocked the user / MEDIUM = slowed down / LOW = minor inconvenience)

Calibration falsifiability review. Read ## Outcome Metrics from the last ≤ 3 plan-summary.md archives and confront the methodology's calibration constants with the observed data — P16 pushback thresholds (3/5/8), root-cause escalation thresholds (2/3/4), sprint complexity budget. Contradiction examples: pushback never triggered across 3 sprints for a beginner profile; fix_rounds/review_rounds rework consistently high with zero devil-advocate escalation; velocity stuck below 60 % of budget for 3 sprints. Each contradiction becomes a regular observation (theme: "calibration") that flows through 2.2 → 2.3 like any other — the improvement proposal is a threshold recalibration, routed through the existing methodology-ticket flow (no dedicated mechanism). Skip silently if fewer than 2 archives carry the metrics section (pre-v0.67 sprints).

2.2 — Synthesize into themes

Group observations by theme. The agent is explicit about what was merged. Multiple observations of the same theme become ONE consolidated theme entry.

Derive for each theme:

• Effective practices (what worked well within this theme)
• Friction points (what slowed down)
• Missing capabilities (what was absent)
• Improvement proposal (concrete, actionable)

2.3 — Closure Gate (3 options)

Present the user with:

I've consolidated {N} methodology observations from this sprint, grouped
into {M} themes. How should I route them?

1. Export as a local feedback document only
   → docs/sprints/sprint-{NN}/methodology-feedback.md
   You can share or submit it manually (email, chat, issue tracker).

2. Propose GitHub tickets (quality-filtered, theme-grouped, deduplicated)
   → I'll walk you through each proposed issue for validation before
     submission to the GSE-One plugin repository via /gse:integrate Axe 2.

3. Both — export AND propose tickets.

4. Discuss — I'll show a one-line-per-observation summary first.

If no observations were gathered (rare, but possible on a smooth sprint) → skip the Gate silently with: "No methodology observations worth escalating this sprint."

If no upstream repository resolves (resolution order: config.yaml → github.upstream_repo → plugin manifest repository field → none) or if config.yaml → github.enabled: false → options 2 and 3 are hidden; only option 1 (local export) is offered.

2.4 — On option 1 or 3 (local export)

Write docs/sprints/sprint-{NN}/methodology-feedback.md using the methodology-feedback.md template (plugin/templates/sprint/methodology-feedback.md — authoritative format). The file is a standalone, shareable artefact with:

• Summary (1-3 sentences)
• Observations grouped by theme (observation, source refs, user quote if relevant, proposed improvement)

Inform the user: "Methodology feedback exported to docs/sprints/sprint-{NN}/methodology-feedback.md. You can share this file through any channel (email, chat, manual issue)."

2.5 — On option 2 or 3 (ticket proposals — quality filter)

Apply the hard constraints before proposing:

1. Concrete — drop themes whose observations don't cite at least one specific example (file, timestamp, user quote, artefact ID). Alternatively, ask the user to specify.

2. Theme-grouped — one ticket per theme, never per micro-friction. Be explicit about what was merged.

3. Dedup — before proposing each ticket, run:

   gh issue list --repo <upstream> --state open --search "<theme keywords>" --json number,title
   

   Annotate each proposal with its dedup status (No match / Potential match: #NNN / dedup unverified (gh unavailable)).

4. Cap — read config.yaml → compound.max_proposed_issues_per_sprint (default: 3). If more themes qualify than the cap allows, prioritize by severity (HIGH > MEDIUM > LOW) and consolidate the rest into the local export only.

5. Per-ticket Gate — present each proposed ticket individually:

   **Proposed ticket {i} of {N}:**
   
   Title: {~60 chars}
   Label: enhancement | bug | documentation
   Body:
     Context: {what the user was trying to do}
     Observation: {what went wrong or was awkward + source refs}
     Proposed change: {actionable}
     Sources: {list of refs}
   Dedup check: {as above}
   
   Options:
   1. Approve — queue for /gse:integrate Axe 2 submission.
   2. Edit — adjust title/body/label before queueing.
   3. Skip — exclude this ticket.
   4. Discuss.
   

6. Prepare the handoff — write approved tickets to .gse/compound-tickets-draft.yaml for /gse:integrate Axe 2 to consume.

2.6 — Persist summary in compound.md

Record a short methodology section in docs/sprints/sprint-{NN}/compound.md with:

• Count of observations collected
• Count of themes
• Route chosen (export / tickets / both / none)
• References to the methodology-feedback.md and compound-tickets-draft.yaml files if produced

2.7 — Summarize raw workflow observations (coach ledger maintenance)

After the methodology feedback is routed, the agent maintains the coach's cross-sprint ledger (.gse/status.yaml → workflow_observations[]) by condensing the current sprint's raw entries into summarized ones. This step preserves historical signal for the coach's trend-based axes (quality_trends, sprint_velocity, sustainability — each requires ≥ 3 sprints of history per design §5.17) while keeping the ledger bounded in size.

1. Read raw entries — filter workflow_observations[] to entries where sprint == current_sprint AND summarized != true. If the filter returns zero entries (coach disabled this sprint, or no observations fired), skip the remaining substeps silently.

2. Group by axis — partition the raw entries by their axis field. Each of the 7 workflow axes that actually fired during the sprint will produce ONE condensed summary entry.

3. Condense per axis — for each axis, produce a summary entry capturing the sprint's signal for that axis. The exact schema is left to the coach sub-agent's judgment (to preserve the anti-rigidity principle), but suggested fields are:

   • axis: the axis name (same as the raw entries grouped)
   • sprint: current sprint number
   • summarized: true (mandatory — distinguishes from raw entries)
   • timestamp: end-of-sprint timestamp
   • summary_text: a 1-3 sentence narrative of what the axis observed this sprint
   • key_observations: [refs] — optional references to particularly salient raw entries
   • severity_trend: optional qualitative assessment (e.g., "improving", "stable", "degrading")
   • count_raw_entries: number of raw entries condensed

4. Write summaries back to workflow_observations[]. The raw entries MAY be deleted once summarized (to save space) OR retained with a reference from the summary — at the agent's discretion, as long as the axis signal is preserved.

5. Bounded growth — this mechanism keeps status.yaml manageable: each sprint adds at most 7 summarized entries (one per workflow axis), regardless of how many raw entries the coach produced. After 10 sprints, the ledger holds approximately 70 condensed entries plus the current sprint's raw entries.

6. Report in compound.md — append to the methodology section (from 2.6) a one-line entry: "Workflow ledger: {N_raw} raw observations from {M_axes} axes condensed into {M_axes} summary entries for cross-sprint trend analysis."

Step 3 — Axe 3: Competency Capitalization

At the start of Axe 3, the orchestrator invokes the coach agent with moment: /gse:compound Axe 3 feed (per coach.md Invocation contract, design §5.17). The coach activates axis 1 (pedagogy — to identify learning opportunities from the sprint's activity) and axis 2 (profile_calibration — to detect drift signals that may warrant /gse:hug --update). Coach outputs feed the substeps below.

Feed the user's learning journey:

1. Update learning notes — Based on sprint activity, aggregate contextual tips:

   • New tools or techniques the user encountered
   • Concepts that required explanation during the sprint
   • Skills demonstrated (evidence of growth)

2. Update competency map — In profile.yaml, adjust competency assessments:

   • Increase confidence for skills practiced successfully
   • Identify gaps revealed by sprint challenges
   • Suggest next learning targets

3. Proactive LEARN proposals — This is the natural moment to propose learning items:

   • "During this sprint, you worked with {topic}. Would you like me to add a learning note about {specific concept}?"
   • Present as low-pressure suggestions, not requirements

Step 4 — Persist and Finalize

1. Write docs/sprints/sprint-{NN}/compound.md with all three axes
2. (Cursor fields last_activity, last_activity_timestamp, and current_phase are maintained centrally by the orchestrator after the activity closes — see plugin/agents/gse-orchestrator.md — section "Sprint Plan Maintenance", and gse-one-implementation-design.md §10.1 — Sprint Plan Lifecycle (v0.53.0). COMPOUND writes no cursor fields directly; the prior current_phase: LC03 write was redundant with /gse:deliver Step 9.3 and is retired in v0.59.1.)
3. Report capitalization summary:
   • Patterns documented: {count}
   • Lessons learned: {count}
   • Methodology proposals: {count}
   • Learning notes added: {count}
4. Proceed to Step 5 (archival), then propose /gse:integrate

Step 5 — Sprint Archival (scalability)

After capitalization, archive the completed sprint to keep state files lean:

1. Backlog compaction — Move all TASKs with status: delivered for the completed sprint from backlog.yaml to backlog-archive.yaml (same YAML format). This keeps the active backlog within ~200 lines.

   • For beginners: "I'll move the completed items to an archive so your task list stays clean."

2. Sprint directory archival — If there are more than 2 completed sprint directories in docs/sprints/, propose (Inform) moving older ones to docs/archive/:

   • Move docs/sprints/sprint-{NN}/ → docs/archive/sprint-{NN}/ for sprints older than current - 2
   • The 2 most recent sprints stay in docs/sprints/ for easy reference

3. Archive accessibility — Archived data is not deleted, just moved. It remains accessible via /gse:status --history or by reading docs/archive/ directly.

4. .gse/plan.yaml handling — explicit no-op here. The durable archive of the sprint plan is docs/sprints/sprint-{NN}/plan-summary.md (produced by /gse:deliver Step 9.1 — inherits gse.id: PLN-NNN from .gse/plan.yaml for P6 traceability). .gse/plan.yaml itself is not moved by this step — it remains in .gse/ with status: completed (sprint-freeze marker) until /gse:plan --strategic opens the next sprint and overwrites it with a fresh plan. During that gap between compound and next-sprint open, the sprint-freeze Hard guardrail (orchestrator) prevents write activities from mutating the frozen sprint.

5. Regenerate dashboard — Run python3 "$([ -s .gse/registry ] && cat .gse/registry || cat ~/.gse-one)/tools/dashboard.py" to update docs/dashboard.html with capitalization results, archived sprints, and updated health trends. Inform the user:

   • For beginners: "The dashboard has been updated with the summary of this cycle. You can open it to see the full project history." (adapt wording to the user's language)
   • For intermediate/expert: "Dashboard updated with compound results and sprint history."

6. Propose next step: /gse:integrate to route solutions to their targets