Handbook
Forge & planning — naming reference
Quick map of terms, plain meaning, and where each is defined in this blueprint (blueprints/ repo). Paths are repo-relative from the blueprints root.
| Term | Meaning (short) | Where stored / documented |
|---|---|---|
| Product Spark | Potentially shippable product slice: PoC, MVP, or phased increment — not the same as a Forge Spark (task). Aliases (same meaning, contextual): release slice, product increment. | Planning flow — vision to daily Sparks · Forge — major processes & flow maps · product-manager/forge-product-manager.mdc.template (§ Forge vocabulary) |
| Meeting | Scheduled, accountable team collaboration (daily sync, refinement, planning, review, retro, Assay Gate). Preferred public label for Forge events in prescriptive docs. | Forge — ceremonies & events (prescriptive) · Forge — meeting model (operational) · Forge — connection to the SDLC foundation |
| Meeting delivery mode | How a meeting is run: human-only, hybrid, or Versona-only (prepare, simulate, synthesize, draft—not a substitute for human sign-off on binding decisions). | Forge — meeting model (operational) |
| Ceremony | Blueprint foundation term: recurring collaboration mapped to intent types C1–C6 in Software development lifecycle. Names the same events as meetings when describing foundation fit. | Ceremony foundation (methodology-neutral) · Forge — ceremonies & events (prescriptive) |
| Why (vs For what) | Why = rationale, motivation, problem framing. For what = beneficiary, outcome, target decision, or practical purpose. Keep both distinct in meeting design—do not merge into one vague field. | Forge — ceremonies & events (prescriptive) (preamble) |
| Forge iteration | Delivery cycle (often 1–2 weeks) inside a Product Spark; scope and evidence assessed at the boundary. | Planning flow — vision to daily Sparks · Forge — major processes & flow maps |
| Ore | Raw, unrefined intake — ideas, problems, opportunities — before refinement. | Forge — major processes & flow maps · Planning flow — vision to daily Sparks · Product planning |
| Ingot | Refined, plannable work (often story-level) with acceptance criteria. | Forge — major processes & flow maps · Planning flow — vision to daily Sparks |
| Forge Spark | Smallest delivery unit: executable task (~1–4 h), often phase-prefixed (discover:, specify:, …). Maps to WBS task. Not an exploration spike. |
Forge — major processes & flow maps (§ Spark = Task, exploration spike contrast) · Planning flow — vision to daily Sparks · Forge — deep-dive package (blueprint) · Forge — connection to the SDLC foundation |
| Charge | Today’s selected Forge Sparks (daily commitment). | Forge — major processes & flow maps · Daily operations · Charge — YYYY-MM-DD |
| Assay Gate | Evidence-based release decision (market-ready vs code-only, etc.). | Planning flow — vision to daily Sparks · product-manager/forge-product-manager.mdc.template · Assay Gate — {Product Spark name} |
| Ember Log | Decision journal — trade-offs, risk acceptance, scope/priority changes (ember-logs/YYYY-MM-DD.md). |
Daily operations · scripts/forge-ember.sh · Ember Log — YYYY-MM-DD · Versona framework — kinds, interfaces, processes, sessions |
| Day journal | Dated operational log (e.g. forge/journal/YYYY-MM-DD.md) — sessions, outcomes. |
Journal — YYYY-MM-DD · Versona framework — kinds, interfaces, processes, sessions |
| Exploration spike / discipline spike | Time-boxed learning; outcome is evidence + record; not a Forge Spark. | Discipline exploration spike — lifecycle and anchors · Forge — major processes & flow maps |
| Product spike (informal) | Colloquial: discipline spike on product/strategy; use spike_discipline + Product Management lens — not a fourth official type, not a Product Spark. |
Discipline exploration spike — lifecycle and anchors §1 |
Milestone (M1…) |
WBS / roadmap milestone; often aligns with one Product Spark. | Planning flow — vision to daily Sparks (§ Mapping to WBS) · Work breakdown structure — [Product / Initiative Name] · Roadmap — {project name} |
| Theme / Epic / Story / Task | WBS hierarchy; Task ↔ Forge Spark when using shared IDs (e.g. M1E1S1T1). |
Planning flow — vision to daily Sparks · Work breakdown structure — [Product / Initiative Name] · Product bootstrap flow — from zero to first Charge |
| Product hat (and other hats) | Product vs Engineering vs Challenge vs Governance perspective when deciding. | Forge — roles (prescriptive) · versona/catalog/discipline/product/versona-product-management.mdc.template (baseline) |
| Versona | Discipline virtual persona (§5 structured concern report when used); templates under versona/catalog/. |
Versonas — discipline-focused virtual personas · Versona contract · Versona framework — kinds, interfaces, processes, sessions |
| Versona session | One interaction with a Versona—folder under forge-logs/versona/<actor>/<session-id>/; may include several activities. |
Versona framework — kinds, interfaces, processes, sessions §1 · Forge — major processes & flow maps |
| Challenge pass | Informal name for a §5-shaped discipline review (pressure-test); one possible session/activity type—not what “Versona” means globally. | Versona framework — kinds, interfaces, processes, sessions §1 · Versona contract §5 |
| Forge Product Manager (agent) | Dialog agent: bootstrap, roadmap → WBS → Product Spark → Sparks → Charge (orchestration). Uses Roadmap Definition of Ready before WBS; suggests a Product Management Versona session after roadmap draft. | product-manager/forge-product-manager.mdc.template · Product bootstrap flow — from zero to first Charge · Product Manager — Forge orchestrating agent |
| Product Management Versona | Template scope (not the global Versona definition): challenge-oriented product-strategy pass—strategy, roadmap coherence (incl. roadmap DoR), Product Spark fit, Assay — not BA/PM-governance/UX/SE scope. Output adds Suggested next Versonas (see Versona contract §5). | versona/catalog/discipline/product/versona-product-management.mdc.template · versona/catalog/workflow/versona-roadmap-gate.mdc.template (optional gate) |
forge-logs/ |
Spark-level notes, DoD, journals; Versona sessions under forge-logs/versona/<actor>/<session-id>/. |
Forge — major processes & flow maps · Versona framework — kinds, interfaces, processes, sessions |
Work item kind (work_item_kind) |
Session/manifest: e.g. spark, spike_discipline, spike_general. |
Versona framework — kinds, interfaces, processes, sessions · Versona session — ../../templates/forge/session.manifest.yaml.template |
| Tracking spine (commits ↔ work units) | Methodology-neutral model: contributors, events, linkage — supports traceability alongside Forge. | Tracking foundation (single spine) · Forge — connection to the SDLC foundation |
Why vs For what
Why = rationale, motivation, problem framing. For what = beneficiary, outcome, target decision, practical purpose. In prescriptive meeting design, keep both explicit—do not collapse into one vague “purpose” field. (Summary also appears in the table above.)
Meetings vs ceremonies vs Versona sessions
These are not three competing “object types.” Meetings are what goes on the team calendar and carries human accountability. Ceremonies are how this blueprint ties those same events to C1–C6 intents. Versona sessions are bounded discipline work (folder under forge-logs/versona/, one or more activities)—including challenge passes, drafting, and spikes—not a replacement for daily sync, retro, or gates.
Seven-phase benchmark vs Forge PDLC (P1–P6)
External literature often uses a seven-phase product-development benchmark (e.g. discovery → scoping → business case → design/prototype → development → test/validate → launch/learn). Forge does not claim a universal seven-phase standard; it publishes P1–P6 in Product development lifecycle (PDLC), with SDLC (Discover / Prioritize → … → Release) as the Build & release engine nested after P3—see the SDLC — Build & release subsection there. The full benchmark table and terminology cautions (Release vs Launch, two “discovers,” two “validates”) live in PDLC.md § Benchmark map. Use the short table below when comparing to seven-phase models; avoid implying Forge has exactly seven public PDLC phases.
| Benchmark (7-phase style) | Nearest Forge anchor |
|---|---|
| Discovery | P1 Discover problem; overlaps SDLC Discover / Prioritize when validated work enters the delivery backlog |
| Scoping / screening | P1 exit / P2 Validate solution entry |
| Business case / planning | P3 Plan & Commit |
| Design / prototype | P2 (prototypes, experiments) + SDLC Design (C) |
| Development | SDLC Build (D) |
| Test and validate | SDLC Verify (E); P2 evidence for solution fit |
| Launch and learn | SDLC Release (F) → P4 Launch → P5 Grow |
Note: P6 Sunset, dual-track overlap, and full obligations live in Product development lifecycle (PDLC).
Related
- Concept matrix, per-concept detailed notes, and term-collision register (expanded): ForgeSDLC — concept map and term-collision register
- Lifecycle bridge (Forge ↔ PDLC ↔ SDLC): Forge ↔ SDLC ↔ PDLC bridge
- PMI-style phase map (problem → delivery): Product creation → delivery — industry, Forge, and PMI-style map
- Forge package index: Forge — deep-dive package (blueprint)
- Published overview (external): forgesdlc.com methodology overview
Blueprint reference — update when planning or Versona contracts change.