Stage 0 interrogation
User Flow Map Round 1: AFPS Tracker
Confirm or correct the initial flow assumptions before any canonical design-tree or flow-map artifacts are written.
Resolved Context
Invocation: $user-flow-map research/afps-tracker
Product path: research/afps-tracker. The path is active in research/.progress.yaml; exec-loop-tracker remains a separate active product path.
Approved source artifacts used: idea-brief.md, icp.md, competitive-analysis.md, journey-map.md, positioning.md, glossary.md, research/.progress.yaml, AGENTS.md, and CLAUDE.md.
Round purpose: establish persona, entry points, first success, branch boundaries, surfaces, states, failures, handoffs, and non-goals before the flow map stage.
Assumptions Manifest
For each assumption, choose confirm, correct, or flag. Corrections and flags will seed the next interrogation pass or the flow assumptions checkpoint.
[from positioning] The primary persona is an individual AFPS power user or AI-workflow operator running multi-branch, repo-local product discovery; buyer and user are usually the same person.
[from journey] The core job is to understand and resume a research-stage AFPS product portfolio by seeing product paths, statuses, pipeline stages, evidence refs, and approval provenance without opening several files.
[from journey] The flow starts when branch or artifact sprawl becomes expensive: multiple product paths, a restarted or compacted agent session, feedback on an alignment page, or a future-self/collaborator question about why a path exists.
[from journey] The first success condition is a correct source-linked read-through over a real AFPS repo: active and parallel paths, stage progression, evidence refs, and approval provenance become legible and verifiable.
[from idea] AFPS Tracker is passive and research-phase scoped. It is not a generic PM tool, not a development execution tracker, not an active recommender, and not a replacement for the AFPS skills.
[from positioning] The v1 flow should be read-first and non-destructive: source fidelity, freshness, and evidence links come before editing or write-back.
[inferred] Likely flow surfaces include a portfolio overview, product-path detail, source/evidence inspector, approval/provenance view, freshness/parser status, and optional export or handoff summary. This is enough surface count to likely use chunked flow mapping after approval.
Open Flow Questions
1. What is the primary flow to map first?
Recommended: map the first real repo read-through, from opening AFPS Tracker on an existing repo to trusting the displayed branch map enough to resume work.
Map the first real repo read-through: the operator opens AFPS Tracker on an existing AFPS repository, sees active and parallel product paths, verifies stage/provenance/evidence links against source artifacts, and resumes the correct next research step.Agent confidence: high
2. Which entry points must the flow include?
Recommended: include direct repo/project open, session-resume prompt, alignment-index link, and a "why is this path here?" review moment.
Include entry points for opening the tracker from the repo, resuming after a Codex/Claude session restart or compaction, following from an alignment/index or progress artifact, and answering a future-self/collaborator question about why a branch exists.Agent confidence: medium
3. What is the happy path sequence?
Recommended: scan portfolio, choose a path, inspect evidence/provenance, verify source freshness, then leave with the next AFPS command or a clear branch-state answer.
The happy path is: scan the portfolio overview; select the relevant product path; inspect its pipeline stage, status, reason, evidence refs, and approval provenance; verify source freshness and parser confidence; then resume with the next AFPS command or answer the branch-state question.Agent confidence: medium
4. Which alternate paths and branches matter?
Recommended: branch on single-path vs multi-path repos, stale/missing artifacts, archived/deferred/promoted paths, evidence-review depth, parser uncertainty, and read-only vs future gated edit intent.
Map branches for single-path versus multi-path repositories, stale or missing artifacts, archived/deferred/promoted paths, evidence-deep-dive versus quick scan, parser uncertainty, and a future gated-edit intent that is noted but not part of read-first v1 completion.Agent confidence: medium
5. Which surfaces are likely required?
Recommended: portfolio overview, product-path detail, evidence/source inspector, alignment/provenance view, freshness/parser diagnostics, and export/handoff summary.
Likely surfaces: portfolio overview, product-path detail, evidence/source inspector, alignment/provenance view, freshness/parser diagnostics, and export or handoff summary. All are visual UI candidates; diagnostics may also have non-visual validation/audit output later.Agent confidence: medium
6. Which states and edge cases must be represented?
Recommended: empty repo/no product paths, loading, parse error, stale source, partial evidence refs, permission-denied file access, offline/local-only, validation warnings, success, and promoted-path handoff.
Represent empty/no product paths, loading, parse error, stale source, partial evidence refs, permission-denied file access, offline or local-only operation, validation warnings, success, archived/deferred/revisit/promoted path states, and promoted-path handoff out of AFPS Tracker scope.Agent confidence: high
7. What handoffs must the flow preserve?
Recommended: handoff to the next AFPS skill command, future self, another agent session, a collaborator/client evidence review, and promoted branch handoff to a separate execution tracker.
Preserve handoffs to the next AFPS skill command, future self, another Codex/Claude agent session, collaborator or client evidence review, and promoted branch handoff to a separate execution tracker rather than continuing development tracking inside AFPS Tracker.Agent confidence: medium
8. What should be explicit non-goals for the flow map?
Recommended: no generic PM workflows, no development execution tracking, no autonomous recommendations, no production architecture, no database schema, no high-fidelity UI, and no write-back as first-success criteria.
Explicit non-goals: generic PM workflows, development execution tracking, autonomous recommendations or nudges, production architecture, database schema, high-fidelity UI, and write-back as first-success criteria. Read-first verification is the v1 flow boundary.Agent confidence: high
Confidence Gate Coverage Targets
| Area | Current status after this round |
|---|---|
| Persona, role, and goal | Covered by assumptions; user can correct primary persona and goal. |
| Entry points and triggers | Covered by assumptions plus open entry-point question. |
| First success or completion condition | Covered by assumptions; user can correct first-success definition. |
| Happy path and alternate paths | Open questions collect happy path and branch boundaries. |
| User, system, permission, and external decisions | Partially inferred; branch and state answers will decide whether a second round is needed. |
| Screens/routes/surfaces and states | Open surface and state questions collect the required inventory seed. |
| Failure and recovery paths | Initial edge states are proposed; user can add failures and recovery expectations. |
| Cross-role, cross-device, manual handoffs | Open handoff question collects future-self, agent, collaborator/client, and execution-boundary handoffs. |
| Flow boundaries and non-goals | Covered by assumptions plus explicit non-goal question. |
Compile Responses
Use this after answering or applying recommendations. Paste the compiled YAML back into the agent to continue $user-flow-map research/afps-tracker.