Forge — ceremonies & events (prescriptive)

Meeting model (delivery modes, accountability, per-meeting detail): Forge — meeting model (operational).

Each Forge ceremony below lists inputs, outputs, participants, timebox, agenda, and Forge-specific mechanics. Forge keeps standard ceremony names and adds precision inside them.

Default iteration length: 1 week (configurable to 2 weeks for exploratory work).

---

0. Ongoing — Ore intake

Intent: Capture new ideas, requests, issues, and opportunities as Ore before they enter the commitment pipeline.

Prescriptive rule: Do not refine or commit Ore during intake. Capture enough for triage; avoid detailed commitments.

---

1. Refinement (Ore → Ingot)

Intent: C1 (Align) + C2 (Plan the slice) — shape selected Ore into Ingots.

Agenda:

1. Product hat presents top Ore items (5–10 min).
2. Clarify problem, value, and constraints; Engineering hat assesses feasibility (15–20 min).
3. Invoke Versonas on high-risk or high-value items — time-boxed session (10–15 min).
4. Decide: promote to Ingot, merge, Bank, or reject. Document decisions in Ember Log (5–10 min).

Definition of Ready (Ingot):

• Problem and value statement clear.
• Acceptance criteria testable.
• Key constraints and dependencies identified.
• Estimated effort range (fits iteration horizon).
• Phase affinity identified (discover/specify/design/build/verify/release).

---

2. Planning (Ingot → Sparks)

Intent: C1 + C2 — decompose Ingots into Sparks and scope the iteration.

Agenda:

1. Product hat proposes iteration focus and highest-value Ingots (10 min).
2. Engineering hat decomposes Ingots into Sparks (30–45 min).
3. Sequence Sparks by risk reduction and learning value (15 min).
4. Confirm scope fits capacity; intentionally leave margin for interruption (10 min).
5. Identify Versona sessions needed before key Sparks begin (5 min).

Spark quality check:

• One clear intent.
• One primary expected outcome.
• One practical acceptance route.
• Limited dependency surface.
• Completable in one focused session (~1–4 hours).
• Phase prefix assigned.

---

3. Daily sync (Charge confirmation)

Also called: Daily sync meeting (same event).

Intent: C3 — execute and unblock; confirm today's Charge.

Agenda:

1. Review yesterday's Charge: what completed, what carries forward (3 min).
2. Confirm today's Charge: which Sparks are active (3 min).
3. Surface blockers and Banking decisions (3 min).
4. Declare hat for the day's primary focus (1 min).
5. Identify any Versona sessions needed (2 min).

Prescriptive rule: The Charge should be intentionally smaller than theoretical capacity, leaving room for interruption, rework, and learning.

Same-day follow-up: When the sync surfaces a blocker, a need for replanning, or a discipline Versona, schedule a separate, time-boxed session afterward—analogous to the Scrum Guide’s Daily Scrum plus optional follow-on collaboration. Do not add standing extra sync meetings that only repeat status without new decisions or outcomes.

---

4. Review (evidence assessment)

Intent: C4 (Inspect) + C6 (Assure) — inspect what was achieved and assess evidence quality.

Agenda:

1. Engineering hat demonstrates working increment (30 min).
2. Product hat assesses against Ingot acceptance criteria (15 min).
3. Versona session: discipline-specific review of increment quality (15 min).
4. Governance hat reviews evidence against Assay Gate criteria (10 min).
5. Decide: ready for Assay Gate, needs more evidence, or scope adjustment (10 min).

---

5. Assay Gate (release readiness)

Intent: C6 — evidence-based release decision. Separate from Review to keep the question strict: is this releasable?

Evidence types (configured per work type):

• Tests passed (unit, integration, E2E as applicable).
• Acceptance criteria met and documented.
• Risk checks completed (security, compliance Versona if applicable).
• Performance / quality thresholds met.
• Stakeholder validation completed (for user-facing changes).
• Rollback or support readiness confirmed.

Prescriptive rule: Work that fails the Assay Gate is not failure — it is simply not yet releasable. Adjust scope or gather more evidence; do not lower evidence standards under schedule pressure.

---

6. Retro (learning → new Ore)

Intent: C5 — reflect and improve the system of work.

Agenda:

1. Review metrics: Spark throughput, Charge completion rate, Assay Gate results (10 min).
2. Ember Log review: which decisions worked, which assumptions were wrong (10 min).
3. Versona effectiveness: which sessions added value, which created noise (10 min).
4. Generate insights: patterns, systemic issues, process friction (15 min).
5. Commit to 1–3 experiments with owners and due dates (10 min).
6. Feed learnings back as new Ore where applicable (5 min).

From retro to directives

Retros must be documented enough that tooling or Versonas can turn outcomes into updates to project directives—Markdown files that govern how the team works (e.g. project sdlc/ rules, .cursor/rules/, team norms, ADR-style process decisions). The meeting stays human-first; the loop below adds structure so discussion does not end as vague chat.

Minimum bar for any directive change (same as before):

• Evidence — link to retro notes, metrics, or Ember Log entries that justify the change.
• Owner — named human accountable for the change (may align with the retro experiment owner).
• Approval — explicit sign-off per team governance (e.g. tech lead + product for SDLC rule changes).
• Review / expiry — date or trigger for revisiting the directive; avoid stale rules with no owner.

Recommended retro-to-directive loop

1. Retro — Run § Retro (learning → new Ore) as usual; capture raw notes in the team’s usual place.
2. Retro Record — Consolidate themes, evidence pointers, and committed experiments using Retro Record — — — . Why and For what are required at retro and theme level.
3. Triage — Tag each signal: experiment only | working agreement | project SDLC directive | technical directive | ADR | Ember Log only. Default: experiment or Ember Log unless the team explicitly escalates.
4. Directive Change Proposal (DCP) — For items that may change governed Markdown, draft Directive Change Proposal — DCP-- before merge (scope, evidence, approval path, review/expiry, rollback).
5. Human approval — Approvers act per Routing retro outputs below; Versonas do not approve.
6. Apply — Merge updated directive files (