The UI is for an AFPS power user or AI workflow operator returning to a repo-local AFPS portfolio after context loss, restart, compaction, or handoff.
UI Interview Round 1: Quick-Scan Overview
Confirm the starting assumptions for the quick-scan-overview UI experiment under uf-orient-portfolio. This round must be answered before I can design the concrete UI mockup or write a UI branch packet.
Resolved Context
Product path
research/afps-tracker, resolved from the approved flow tree and UX variation artifact.
Selected branch
quick-scan-overview, approved under parent flow uf-orient-portfolio.
Primary surface
Portfolio Overview: scan-first, row-selection driven, source warnings visible but secondary to quick orientation.
Prototype boundary
UI-interview may propose a static or lightly interactive mockup only. Clickable screen buildout waits for $build-ui-screens after UI approval.
AFPS Tracker
activepositioning1 warning
Representative active row with visible stage, trust level, next skill, and warning count.
Exec Loop Tracker
parallel activeboundary
Representative parallel path that must remain visible without becoming the selected AFPS research route by accident.
Assumptions Manifest
Confirm, correct, or flag each assumption. Corrections will drive the next interrogation round or the UI proposal.
The UI experiment stays inside uf-orient-portfolio: open tracker, scan active and parallel paths, understand source health at a glance, select a path, then route to selected-path verification. It must not absorb evidence inspection, diagnostics recovery, handoff/export, or inactive/promoted boundary explanation.
Quick-Scan must coordinate with sibling flows by handing selected-path context to verification, warnings to diagnostics, evidence/provenance requests to inspection, and inactive or promoted rows to boundary explanation.
The UI proposal should cover these states as one overview-centered experiment: loading scan, portfolio overview, selected-row preview, empty/no-AFPS state, and blocking diagnostic summary. A future experiment route can be /experiments/quick-scan-overview.
The hierarchy should be compact and operational: source-health strip and counts first, active paths next, parallel/context paths after that, then row-level warnings, boundary labels, and secondary diagnostics links.
Expected controls are select path row, group filter/toggle, inspect source health, review row warnings, continue to verify selected path, and explain boundary. Required states are empty, loading, partial, clean, warning, blocked, selected, disabled, permission-denied, unresolved, inactive, and promoted.
The visual direction should be restrained, utilitarian, source-aware, and not marketing-like. The mockup can use fake fixture data and should not commit to production storage, auth, parser implementation, file watchers, analytics, payment, deployment, or write-back.
Open UI Questions
How prominent should warnings be in the first screen?
Quick-Scan depends on warnings being visible without turning the page into the diagnostics-first variation.
Recommended: use a persistent source-health strip plus row-level badges. Blocking issues interrupt the quick path with a banner, while non-blocking warnings stay visible but do not prevent row scanning.
Use a persistent source-health strip plus row-level warning badges. Blocking issues should interrupt the quick path with a banner; non-blocking warnings should remain visible without taking over the overview.
Agent confidence: high
How much selected-path detail belongs in the orientation screen?
The selected-row preview needs enough confirmation to make the next click feel safe, but selected-path verification owns the real detail.
Recommended: show a compact preview with selected path label, status, stage, trust level, warning count, and disabled/enabled reason for "Continue to verify path." Do not show copy-next-command or full evidence/provenance detail here.
Show a compact selected-row preview with label, status, stage, trust level, warning count, and the enabled or disabled reason for Continue to verify path. Exclude copy-next-command and full evidence/provenance detail from this orientation screen.
Agent confidence: high
Which layout should the first mockup use as its default?
The branch is list-like by thesis, but the UI proposal still needs a concrete desktop and mobile layout direction.
Recommended: desktop uses a top source-health strip, count summary, grouped path list, and a right-side selected preview that becomes an inline expansion on tablet/mobile. This keeps first value in one screen while preserving responsive scan speed.
Desktop should use a top source-health strip, count summary, grouped path list, and a right-side selected preview. On tablet and mobile, the selected preview should become an inline expansion below the selected row.
Agent confidence: medium
Compile Responses
Answer the assumptions and open questions, then compile YAML and paste it back to the agent.