Review alignment page ยท Stage 1 scope and framework-selection gate
FormForge Journey Map Framework Selection
This page proposes the journey-map research scope and framework set for the active FormForge flat research path. It is a scope gate only: it identifies available source categories and approval questions before any synthesized journey research, working packet, run manifest, framework intermediate, or canonical journey-map artifact is created.
Stage Boundary
No synthesized journey findings are included on this page. The purpose is to approve scope and framework selection before the parent loop writes a run manifest or enters the first framework research phase.
Allowed In This Stage
Resolve scope, identify source categories, detect mode, propose framework set, define output paths, and ask approval questions.
Blocked Until Approval
Framework research, journey synthesis, working-packet creation, run-manifest creation, canonical artifact writes, and downstream routing.
Approval Mechanism
Use the required gate questions and bottom compile control to produce YAML for a fresh `$journey-map` invocation.
Scope Resolution
The active scope resolves to flat research/ mode for FormForge.
| Scope Item | Observed Evidence | Stage 1 Meaning |
|---|---|---|
| Active path | research/.progress.yaml lists active_paths: [research/]. | Use flat single-product output paths. |
| Product path label | formforge, labeled "FormForge current flat scope". | Use topic slug formforge for the alignment page. |
| Prerequisite status | research/icp.md exists and is confirmed. | The hard journey-map prerequisite is satisfied. |
| Prior lifecycle state | No research/_working/journey-map-run.yaml or research/journey-map.md found in the Stage 1 file scan. | Cold state E: build framework-selection review page. |
| Deferred paths | Lead quote forms, event registration, nonprofit volunteer forms, and HR ops forms are marked revisit/deferred in research/.progress.yaml. | Do not promote or map deferred paths in this run. |
Mode Detection
Detected mode: Product-exists mode, based on local product implementation and README/package evidence. The source base shows a Next.js application and product loop; no post-launch customer-feedback file was found.
Product Evidence
README.mddescribes FormForge as an AI-assisted form builder prototype focused on describe, generate, edit, publish, submit, review, and export.package.jsonidentifies a private Next.js app with build, lint, test, database, Stripe, Clerk, OpenAI, and form-builder dependencies.
Customer Evidence Gap
- No
research/customer-feedback.mdwas found. - Journey research should distinguish repo/product evidence from direct buyer or usage evidence in later framework packets.
| Evidence Category | Observed Stage 1 Signal | Strength |
|---|---|---|
| Production app / repo evidence | Next.js app, README product loop, product dependencies. | High |
| Customer feedback evidence | No research/customer-feedback.md found. | Low / absent |
| Approved ICP evidence | Confirmed ICP and competitive analysis exist. | High |
Available Source Categories
This is source availability and research plan context, not journey findings.
| Source Category | Available Inputs | Use In Later Framework Research | Coverage Gap |
|---|---|---|---|
| ICP and current-state journey | research/icp.md, alignment/icp-formforge.html | Primary source for personas, trigger events, pain map, current alternatives, and likely aha moment. | Research-backed, not interview-backed. |
| Competitive landscape | research/competitive-analysis.md plus approved framework intermediates. | Source for alternatives, suite gravity, generic builder pressure, handoff gaps, and validation questions. | No hands-on trials or buyer interviews. |
| Product/repo context | README.md, package.json, Next.js app files in the repository. | Source for product-exists mode and product loop boundaries. | Local implementation is not proof of usage, adoption, or buyer value. |
| Customer feedback | No research/customer-feedback.md found. | Do not use nonexistent customer quotes as evidence. | Later journey packets must keep direct-customer confidence lower where applicable. |
| Journey intermediates | No research/journey-map-*.md found. | State E begins framework selection. | Framework-specific evidence will be generated only after approval. |
Framework Selection
Product-exists mode defaults to service-blueprint and user-story-map. Optional frameworks can be included if the reviewer wants a broader journey artifact set.
Service Blueprint Default
Maps front-stage, backstage, support processes, evidence, and operational gaps. Fit: strong for an existing product loop where intake, submissions, review, export, and handoff need to be grounded in service delivery operations.
User Story Map Default
Maps activity, task, story hierarchy, and release slicing. Fit: strong for a working product boundary because it can connect buyer/user jobs to the describe, generate, edit, publish, submit, review, and export loop.
Customer Journey Canvas Optional
Maps stages, touchpoints, actions, emotions, backstage, pain, and opportunities. Fit: useful if the review should cover the full stage-by-stage customer lifecycle rather than product operations first.
Experience Map Optional
Maps doing, thinking, feeling, channels, pain, and delight moments. Fit: useful for emotional arc and adoption anxieties, but direct customer feedback is currently missing.
JTBD Timeline Optional
Maps first thought, passive looking, active looking, deciding, consuming, and satisfaction through push, pull, anxiety, and habit. Fit: useful if switching behavior needs more structure before positioning.
Loop Plan
- Reviewer approves this Stage 1 scope and framework-selection page through compiled YAML.
- A fresh `$journey-map` session consumes the YAML and writes
research/_working/journey-map-run.yaml. - The parent orchestrator runs exactly one selected framework inline and creates that framework's findings review page.
- Each framework findings page waits for compiled YAML before its canonical intermediate is written.
- After all selected intermediates exist, `$journey-map --synthesize` builds the synthesis review page.
Parent-owned routing: the user should continue through $journey-map, not through child framework commands. The parent resolves pending framework state from the manifest and filesystem.
Output Paths
| Artifact | Path | Timing |
|---|---|---|
| Active review page | alignment/journey-map-formforge.html | Written in Stage 1 for this review. |
| Future run manifest | research/_working/journey-map-run.yaml | Only after approved compiled YAML is consumed. |
| Future framework intermediates | research/journey-map-{framework}.md | Only after each framework findings page is approved. |
| Future synthesis working packet | research/_working/preliminary-journey-map-research.md | Only during synthesis review. |
| Future canonical synthesis | research/journey-map.md | Only after synthesis approval. |
Assumptions And Confidence
| Assumption | Status | Confidence | What Would Change It |
|---|---|---|---|
Flat research/ is the active FormForge scope. | Evidence-backed from progress manifest. | High | New approved product-path YAML or manifest change. |
| Journey-map prerequisite is satisfied. | research/icp.md exists and is confirmed. | High | Archived or superseded ICP approval. |
| Product-exists mode is appropriate. | Inferred from README and Next.js app/package evidence. | Medium-high | User directs pre-product mode, or repo implementation is declared non-representative. |
| Customer-feedback evidence is absent. | No research/customer-feedback.md in the file scan. | High | User provides feedback artifacts, interview notes, analytics, or support logs. |
| Default framework set should prioritize operations and stories. | Policy-backed by product-exists mode. | Medium | Reviewer chooses broader emotional/lifecycle or switching frameworks. |
Stage 2 Preview
After approval, the next fresh `$journey-map` session will create the run manifest from the approved selected framework set and run the first pending framework inline. The framework findings page should include:
- Framework-specific working packet content rendered as structured review UI.
- Evidence matrix distinguishing claims, source evidence, inference, confidence, assumptions, and decision impact.
- Source coverage gaps, especially direct-customer feedback gaps.
- Framework artifact destination and proposed file-change gates.
- Parent-owned
agent_routingback to$journey-map.
Compile Responses
Answer required gate questions and optionally select section feedback. The compiled YAML is the approval or revision payload for the next fresh `$journey-map` session.