Primary user is an AFPS power user or AI workflow operator returning to a repo-local AFPS portfolio after context loss, session restart, or branch-state review.
UX Variations Round 1: Orient To Product Portfolio
Confirm the starting assumptions for varying uf-orient-portfolio, the activation branch where an AFPS operator opens the tracker, scans active and parallel product paths, and selects the path to inspect.
Resolved Context
Selected branch
uf-orient-portfolio in design/afps-tracker/flow-tree-afps-tracker.yaml.
Product path
research/afps-tracker, resolved from the branch and scoped design artifacts.
Fixed model substrate
design/afps-tracker/model-tree-afps-tracker.yaml and domain-model-afps-tracker.md are approved model inputs.
Mode
Default progression-path UX variation mode, not layout-only mode.
1. Orient
Open tracker, scan portfolio, select path.
Open tracker, scan portfolio, select path.
2. Verify
Inspect selected path and trust support.
Inspect selected path and trust support.
3. Inspect
Trace claims to source and provenance.
Trace claims to source and provenance.
4. Recover
Read diagnostics and blocked states.
Read diagnostics and blocked states.
5. Handoff
Generate next-command summary.
Generate next-command summary.
6. Boundaries
Explain inactive or promoted paths.
Explain inactive or promoted paths.
Assumptions Manifest
For each assumption, confirm it, correct it, or flag it as risky. Corrections and flags will drive the next round or the concept set.
The selected branch should stay bounded to orientation: open tracker, scan portfolio, understand active and parallel paths, and select a path. Deeper path verification, source inspection, diagnostics, and handoff remain sibling flows.
The orientation job is source-linked portfolio legibility: quickly see which product paths exist, which are active or parallel, what state they are in, and where to go next without reading several files manually.
The first-value moment is seeing active and parallel product paths, plus enough source-health context, without manual file reading. The aha threshold is selecting a path with confidence that the overview did not fabricate state.
UX variations may change entry emphasis, grouping strategy, path selection sequence, diagnostic visibility, progressive disclosure, navigation model, density, and first-run guidance, but must preserve read-first source fidelity and the approved domain model.
The variations should stay in the product-design tree, avoid prototype buildout before UI approval, use design/afps-tracker for UX artifacts, and keep ordinary branch state out of tasks/todo.md.
Open Variation Questions
Which orientation tension should the variants stress-test most?
This decides whether the five concepts differ mainly by scan speed, trust depth, recovery-first behavior, portfolio grouping, or command/resume orientation.
Recommended: Make this a variant axis and test all approaches: quick-scan overview, trust-first source health, diagnostics-first recovery, portfolio-map grouping, and command/resume-first orientation.
Make this a variant axis and test all approaches: quick-scan overview, trust-first source health, diagnostics-first recovery, portfolio-map grouping, and command/resume-first orientation.
Agent confidence: high
What should stay fixed across all orientation variants?
The domain model stays fixed, but visual density, navigation, evidence preview depth, and warning prominence can vary unless you lock them.
Recommended: Lock only technical stack, read-first source fidelity, approved branch boundary, and trust-envelope semantics. Let navigation, grouping, density, warning prominence, first-run guidance, and handoff preview vary.
Lock only technical stack, read-first source fidelity, approved branch boundary, and trust-envelope semantics. Let navigation, grouping, density, warning prominence, first-run guidance, and handoff preview vary.
Agent confidence: medium
What would make an orientation variant unacceptable?
This will become rejection criteria before the full variation specs are written.
Recommended: Reject any variant that hides source warnings, implies unconfirmed provenance, routes inactive/promoted paths as active next work, requires write-back for first value, or makes the operator read raw files before the overview is useful.
Reject any variant that hides source warnings, implies unconfirmed provenance, routes inactive/promoted paths as active next work, requires write-back for first value, or makes the operator read raw files before the overview is useful.
Agent confidence: high
How should the variants be compared before a branch moves to UI interview?
Default progression mode normally compares proposed branches, then routes approved branches to $ui-interview rather than building prototypes now.
Recommended: Compare the proposed branches by solo evaluator walkthrough against first-value clarity, source-trust visibility, branch-selection speed, recovery safety, and implementation cost; then send the strongest branch to UI interview first.
Compare the proposed branches by solo evaluator walkthrough against first-value clarity, source-trust visibility, branch-selection speed, recovery safety, and implementation cost; then send the strongest branch to UI interview first.
Agent confidence: medium
Compile Responses
Use this after answering the assumptions and open questions. Paste the YAML into the next agent message so the skill can consume it, write the sidecar, and decide whether the confidence gate can advance.