Activities - Run the Iteration

#	Name	Abbrev.	Guidance	Actions
Construction 7
1	Determine Cadence & Iteration Length	RIN-1	Objective Choose the iteration length and collaboration cadence from current team evidence, then record the …	Read the 'RIN-1 Determine Cadence & Iteration Length' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Choose the iteration length and collaboration cadence from current team evidence, then record the decision in `docs/project/iterations/<iteration_id>/ITERATION_FRAME.md`. ## Required inputs - Approved `docs/project/CHARTER.md`, especially Team Roster, maturity classification, and maturity evidence. - Delivery Management Assignment. - Candidate start date and participant availability. ## Procedure 1. Enter the ADE's planning mode when available; otherwise write the execution plan before changing project state. 2. Validate the Charter's maturity assessment. If it is missing or older than one completed iteration, reassess it with the Delivery Manager and team and update the Charter before selecting cadence. 3. Apply the default mapping: - `L2` or `early-L3`: one-week iteration. - `late-L3` or `L4`: one-day iteration. 4. A different length is allowed only when the Delivery Manager records evidence and an expiry/review date. 5. For a one-person team, omit recurring meeting overhead; use asynchronous records and decision points. For larger teams, name only the ceremonies needed for coordination. 6. Create a stable `iteration_id` and record start/end timestamps, maturity/evidence, chosen length, ceremonies/triggers, participants, timezone, exception rationale, and approval. ## Completion evidence The frame exists, the maturity evidence is current, the selected length is mechanically derived or explicitly justified, every ceremony has a purpose and owner, and the Delivery Manager approval is recorded.
2	Set the Iteration Goal	RIN-2	Objective Select one outcome that can be accepted within the iteration frame and make its …	Read the 'RIN-2 Set the Iteration Goal' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Select one outcome that can be accepted within the iteration frame and make its evidence and exclusions explicit. ## Required inputs - Iteration Frame. - Charter goals and gating policies. - Ordered product/delivery backlog. - Previous Iteration Assessment Report, open Risk/Problem tickets, and accepted/deferred IIPs when available. - Current capacity and known dependencies. ## Procedure 1. Review gating tickets first. A `pause_new_work` concern prevents dispatch of new delivery work; a `block_release` concern must be resolved or explicitly waived by the authorized human before release. 2. Select one outcome, not a list of unrelated tasks. 3. State: beneficiary, behavior/result, quantitative or observable success measure, acceptance evidence, excluded scope, dependencies, owner, and why it fits the chosen length. 4. Link each included concern or backlog item. Do not silently absorb work discovered during assessment. 5. Update the Iteration Frame with the goal and obtain Delivery Manager/team commitment. ## Completion evidence The frame contains one bounded goal, objective acceptance evidence, explicit exclusions, dependency owners, ticket-gate disposition, and approval. If the goal cannot fit, reduce it before invoking PIN.
3	Plan the Iteration	RIN-3	Objective Invoke Plan the Iteration (PIN) for the approved goal and produce an accepted, executable …	Read the 'RIN-3 Plan the Iteration' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Invoke Plan the Iteration (PIN) for the approved goal and produce an accepted, executable delivery manifest. ## Procedure 1. Pass PIN the Iteration Frame, Charter, relevant architecture/process context, open gating tickets, and accepted IIPs. 2. Follow PIN's own activity order and planning rules. Enter enforced ADE planning mode when available. 3. Fan out bounded investigation only where PIN permits and only when workers have distinct outputs or read-only scopes. 4. Converge estimates, dependencies, codebase footprints, checkpoints, parallel groups, and human gates into one manifest/milestone. 5. Obtain the PIN approval required before execution. ## Failure handling Do not invoke MIN with a speculative, internally inconsistent, or unapproved plan. If planning reveals that the goal does not fit, return to Set the Iteration Goal and narrow it. ## Completion evidence The accepted PIN output names every scenario/work item, dependency, codebase footprint, checkpoint command, time budget, parallel group, and approval gate. Its goal and iteration ID match the Iteration Frame.
4	Execute the Iteration	RIN-4	Objective Execute the approved manifest through Manage the Iteration (MIN) while Assess the Iteration (AIN) …	Read the 'RIN-4 Execute the Iteration' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Execute the approved manifest through Manage the Iteration (MIN) while Assess the Iteration (AIN) observes independently. ## Procedure 1. Invoke MIN with the accepted PIN output; do not re-plan it inside this activity. 2. When MIN begins, trigger AIN as a separate/background stream against the same project and iteration ID. If the ADE supports subagents or parallel tasks, isolate AIN from delivery-worker contexts. Otherwise schedule AIN checkpoints without blocking independent delivery work. 3. MIN owns delivery dispatch, checkpoints, drift, integration, and its human gates. AIN owns measurement, ticket lifecycle, throughput, coverage, and its final assessment report. 4. Apply the latest assessment signals: - `observe`: record and continue. - `pause_new_work`: finish safe in-flight checkpoints but dispatch no new work until resolved/waived. - `block_release`: continue safe work but do not release until resolved/waived. 5. Never let AIN edit the MIN manifest or production code. Never let MIN mark an assessment concern Green without AIN evidence. 6. Preserve all required human approvals for scope, merge, release, purchase, or external side effects. ## Completion evidence MIN reaches an explicit complete/escalated state; every checkpoint result and drift decision is recorded; the latest AIN run is complete or explicitly pending; gating signals were enforced; and any shipped increment has verified acceptance and release evidence.
5	Hold the Iteration Retrospective	RIN-5	Objective Convert the iteration's delivery and assessment evidence into owned learning without rewriting history. Required …	Read the 'RIN-5 Hold the Iteration Retrospective' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Convert the iteration's delivery and assessment evidence into owned learning without rewriting history. ## Required inputs - Iteration Frame and accepted PIN/MIN records. - Release/acceptance evidence. - Latest complete Iteration Assessment Report and Project-Management Tickets. - Charter and participants named in its Team Roster. ## Procedure 1. Create `docs/project/retros/<iteration_id>.md`. 2. Compare planned versus actual outcome, duration, throughput, quality, coordination, and assessment signals. 3. For each material variance, record evidence, causal hypothesis, impact, and whether it is: - a product/code/delivery concern to track as backlog or Risk/Problem ticket; or - a repeatable process concern eligible for an IIP. 4. Record decisions, action owners, due dates, and experiments. Do not turn every complaint into a process change. 5. Reassess team maturity only when the iteration produced relevant evidence; update the Charter with evidence and date, not intuition. ## Completion evidence The retrospective cites source records, separates fact from interpretation, classifies each concern, assigns every accepted action, records unchanged/open questions, and has participant acknowledgment.
6	Raise Iteration Improvement Proposals	RIN-6	Objective Let any delivery participant propose a bounded change to Junior Edda or its project-specific …	Read the 'RIN-6 Raise Iteration Improvement Proposals' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Let any delivery participant propose a bounded change to Junior Edda or its project-specific application. The Delivery Manager facilitates and records; the team—not the Delivery Manager alone—authors proposals. ## Procedure 1. Review the retrospective, MIN drift/escalations, AIN report, and repeated Project-Management Tickets. 2. Create an IIP only for a repeatable process defect or improvement opportunity. Product defects and one-off project work remain tickets/backlog items. 3. Search open IIPs for the same concern; update or link an existing proposal instead of duplicating it. 4. Write each proposal to `docs/project/iips/<iip_id>-<slug>.md` with: - stable IIP ID and title; - author(s), affected workflow/activity/rule/artifact; - problem and evidence; - proposed change; - expected effect and measurement; - compatibility/migration impact; - owner and decision point; - status: `proposed \| accepted \| rejected \| deferred \| implemented`. 5. Do not edit released Junior Edda directly. Route accepted playbook changes through the applicable governance/PIP mechanism. ## Completion evidence Every IIP has evidence, a bounded change, affected objects, an owner, decision point, status, and duplicate check. It is acceptable to record “no IIP warranted” with rationale.
7	Prepare the Next Iteration	RIN-7	Objective Close the current iteration cleanly and leave an evidence-based entry condition for the next …	Read the 'RIN-7 Prepare the Next Iteration' activity from playbook 'Junior Edda' (workflow 'Run the Iteration'). Follow its guidance when assisting me. ## Objective Close the current iteration cleanly and leave an evidence-based entry condition for the next one. ## Required inputs Iteration Frame, retrospective, IIPs, Project-Management Tickets, latest AIN report, Charter, backlog, and release evidence. ## Procedure 1. Disposition every IIP as accepted, rejected, deferred, or still under review; name owner and decision date. 2. Update the Charter only for approved changes to goals, ownership, maturity, variables, artifact coverage, cadence, or roadmap. Add a dated change log. 3. Carry forward open Risk/Problem tickets with current evidence and gating policy; do not duplicate them. 4. Record a short ordered list of candidate next goals, dependencies, capacity constraints, and mandatory ticket work. 5. Close the current Iteration Frame with actual end time, result, release identifier, assessment report, and unresolved concerns. 6. State the next-entry condition. Do not automatically start a new iteration or pre-authorize its goal. ## Completion evidence The current frame is closed; Charter changes are approved and versioned; every IIP/ticket has a disposition or owner; candidate goals are ordered but not falsely committed; and the next RIN run can begin from the recorded entry condition.

Activities in Run the Iteration