Tasks

0. RI Owner Return Gate

• 0.1 Do not report this owner-console work as complete because an implementation tranche, deploy, or narrow journey check passed. Tranche success is an internal checkpoint only.
• 0.2 Before any "ready for owner review" handoff, verify the full owner-spine gate: Know Data, Add Data, Inspect Data, Recover Problems, and Grant/Connect AI Apps have current desktop and mobile evidence, browser-console/network evidence, and data-truth probes, or each residual gap is explicitly listed as a blocker with owner-visible impact.
• 0.3 Every implementation tranche must name the owner promise it improves, the adjacent promises it could regress, the full-journey evidence required, and the specific residual P0s that remain after the tranche.
• 0.4 Reject rabbit-hole completion: fixes to local copy, labels, counts, or visual details do not close a row unless the owner can complete the intended action end to end without chat context, repo checkout knowledge, hidden CLI memory, or misleading bounded samples.
• 0.5 Keep executing against the next highest-risk owner journey after each verified tranche until the full gate in 0.2 passes or a real blocker is recorded.

1. Feedback And Discovery Synthesis

• 1.1 Read docs/inbox/the owner-feedback-6-18-26.md as discovery input, not a finite backlog.
• 1.2 Capture product-leadership and discovery prior art in docs/research/product-leadership-aperture-and-discovery-2026-06-18.md.
• 1.3 Dispatch taxonomy, IA/model, prior-art, and technical-probe lanes with read-only scopes.
• 1.4 Reap all worker lanes and fold final findings into this change.
• 1.5 Produce a concise opportunity map that links feedback evidence to canonical journeys, canonical root codes, severity, and first implementation wave.
• 1.6 Run an independent red-team review of this master plan.
• 1.7 Incorporate the red-team's required edits and re-run strict validation.
• 1.8 Fold the interaction-contract matrix into the design and spec so implementation lanes cannot satisfy the plan by relabeling bounded samples, hiding individual leaked strings, or self-certifying journey evidence.
• 1.9 Add SLVP interaction-archetype standards so implementation lanes cannot satisfy the plan with correct IA but sub-SLVP controls.
• 1.10 Harvest the completed targeted prior-art lane artifacts into docs/research/.
• 1.11 Complete the missing fresh-owner journey research and synthesis index after the worker lane hit provider limits.
• 1.12 Add a friction-to-SLVP direction note so the owner's documented friction governs solution quality, not only defect discovery.
• 1.13 Dispatch bounded low-reasoning hard-surface charters plus an adversarial alignment review, then promote only the owner-vetted synthesis.

2. Product Model And IA

• 2.1 Decide the owner-facing noun for configured data-producing instances and document the internal/API term mapping.
• 2.2 Produce a route/nav/headline inventory showing current noun drift.
• 2.3 Decide which current surfaces remain primary, which merge, which demote, and which become evidence layers.
• 2.4 Identify route aliases or redirects needed for backwards compatibility.
• 2.5 Produce an owner-reviewed prior-art memo and mock before deciding whether Runs/Syncs merges into Sources or remains a secondary activity view.
• 2.6 Produce an owner-reviewed prior-art memo and mock before deciding whether Explore and stream-scoped record views fully merge or remain separate with shared rendering.
• 2.7 Resolve the Source / Source instance / collector / device hierarchy in owner language, including whether one Source can intentionally have multiple collectors and how that nesting is shown.
• 2.8 Define the owner-route hygiene plan, including whether /dashboard remains an implementation prefix, which clean owner routes should exist, and which compatibility redirects are required.
• 2.9 Produce hard-problem charters for Sources/Syncs/Runs, Add Data, Explore, Recovery, Grants/Connect, Evidence timelines, and fresh-owner onboarding before broad UI implementation.

3. Journey Atlas

• 3.1 Define the canonical journey scripts for Know Data, Add Data, Inspect Data, Recover Problems, and Grant/Connect AI Apps.
• 3.2 Capture desktop screenshots for each journey using live data where safe.
• 3.3 Capture mobile screenshots for each journey using live data where safe.
• 3.4 Capture browser console errors and failed-network evidence for each journey.
• 3.5 Add synthetic fixtures only for missing archetypes that live data cannot safely cover.
• 3.6 Store the atlas in a tracked docs/research or design-note artifact with stable screenshot references.
• 3.7 Add a fresh-owner journey script covering readiness, first source setup, first records, and first AI-client grant without repo-checkout or chat-context assumptions.

4. Technical Truth Matrix

• 4.1 Classify Amazon count mismatch as data bug, projection bug, filter/IA bug, or unknown.
• 4.2 Classify GitHub first-run success versus missing/zero records.
• 4.3 Classify local collector recovery state after dead-letter recovery.
• 4.4 Classify grant package count and internal source leakage.
• 4.5 Classify run/detail/trace navigation and artifact visibility gaps.
• 4.6 Add safe reproduction or inspection commands for each classified gap.
• 4.7 Convert the technical-probe findings into implementation packets for Amazon sample labeling, GitHub first-sync/status honesty, collector coverage diagnostics, grant-package internal filtering, and trace/package pivots.
• 4.8 Add a counts contract packet that distinguishes total held, current filtered result, current page or preview, latest-run yield, and latest-run-with-new-data yield.
• 4.9 Add a drill-through packet for every owner-visible rollup count, including dashboard attention, runs/syncs review counts, grant package counts, credential token counts, and read counts.
• 4.10 Add a full-visibility packet that replaces owner-facing caps with pagination, virtualization, or a direct full-set path; "showing N of M" is accepted only as a preview label, not as the terminal answer.
• 4.11 Add a CTA subject-scoping packet covering "View records", "Explore", "Review", "Reauthorize", "Open Runs", trace links, deployment metadata links, and source/provider setup actions.
• 4.12 Add a setup/recovery liveness packet covering first-sync auto-refresh, recovery CLI progress, upload-drain progress, and terminal reconciliation.

5. Implementation Wave Planning

• 5.1 Write acceptance packets for Wave 1 noun/route spine.
• 5.2 Write acceptance packets for Wave 2 source truth and counts.
• 5.3 Write acceptance packets for Wave 3 add data.
• 5.4 Write acceptance packets for Wave 4 inspect data.
• 5.5 Write acceptance packets for Wave 5 recovery.
• 5.6 Write acceptance packets for Wave 6 grants/reads/connect AI apps.
• 5.7 Write acceptance packets for Wave 7 activity evidence layer.
• 5.8 Write acceptance packets for Wave 8 craft/mobile/delight.
• 5.9 Add cross-cutting acceptance criteria for live status without manual refresh on setup, recovery, and first-sync status pages.
• 5.10 Track collector-side coverage_missing emission as runtime work required by the console product promise.
• 5.11 Add URL/noun hygiene acceptance, including the /dashboard prefix decision and compatibility redirect plan.
• 5.12 Add cross-cutting acceptance criteria for no artificial caps as final UX: every bounded owner list has a next-page, view-all, or virtualization path.
• 5.13 Add cross-cutting acceptance criteria for owner-visible counts: every count has a basis label and every rollup drills through to its counted subjects.
• 5.14 Add cross-cutting acceptance criteria for source setup: proven connectors remain addable for additional accounts, setup captures or echoes an owner label, and source rename reflects everywhere in one render cycle.
• 5.15 Add cross-cutting acceptance criteria for owner/private leakage: no shared owner UI hard-codes private agent names, internal maintenance sources, deprecated aliases, raw connector instance IDs, or protocol/debug terms as normal copy.

6. Delegation And Review

• 6.1 Use waspflow lanes for review, research, screenshots, and narrow implementation packets only after acceptance checks are written.
• 6.2 Run adversarial review on the master plan before implementation begins.
• 6.3 Run adversarial review on each substantive implementation tranche before merge/deploy readiness.
• 6.4 Keep clawmeter and provider budget in the decision loop; use Claude lanes for breadth when OpenAI budget is hot.
• 6.5 Apply the rabbit-hole filter before dispatching implementation lanes; defer real but low-promise-impact defects unless they are tiny opportunistic fixes inside an accepted tranche.
• 6.6 Require every implementation tranche to pass the owner-spine alignment gate before merge readiness.

7. Validation

• 7.1 Run openspec validate redesign-owner-console-product-experience --strict.
• 7.2 Verify the change references tracked research and does not depend only on chat context.
• 7.3 Confirm no product code changes were included in the planning tranche.

8. Acceptance Checks

• 8.1 A reviewer can read the design and identify the six core journeys and primary owner noun.
• 8.2 A reviewer can map every P0 feedback item to a journey row, root cause, and first planned wave.
• 8.3 A worker can receive a future implementation packet without rediscovering the product model.
• 8.4 The plan explicitly says what evidence is required before a UI deploy.
• 8.5 The plan distinguishes what internal agents can prove from what requires the owner or external user walkthroughs.
• 8.6 The plan explicitly preserves full record visibility: no worker may close a count/sample defect by only changing copy if the owner still cannot navigate to the complete backing record set.
• 8.7 The plan treats unreviewed surfaces named by the owner, including schedules, deployment, device exporters, event subscriptions, and Connect AI Apps, as unaudited surfaces rather than implicitly complete.
• 8.8 A reviewer can read Appendix A and identify the SLVP interaction standard for product gestalt, record workbench, setup, source inventory, recovery, access review, evidence timelines, and craft.
• 8.9 Future implementation packets identify their interaction archetype and include pixel/keyboard/live-data acceptance checks for that archetype.
• 8.10 A fresh Docker/Railway owner can follow the documented journey from instance readiness to first source, first records, and first client grant using only console-visible instructions.
• 8.11 The plan defines a measurable alignment gate that predicts the owner's next review: vertical continuity, truth basis, full visibility, subject-scoped evidence, pixel proof, interaction proof, console/network proof, and adversarial proof.
• 8.12 The implementation proves at least one vertical owner-spine slice end to end with desktop/mobile pixels, browser console evidence, data-truth probes, and an adversarial review.

9. Interaction Archetype Application

• 9.1 Add a product-gestalt packet that covers owner job clarity, in-flow explanation, personal-data dignity, no wall-of-text defaults, and shareability review.
• 9.2 Add a record-workbench packet that covers Explore selection affordances, multi-select intent preservation, autocomplete, date controls, sorting, ID jump feedback, time distribution filtering, rich record rendering, and full-set navigation.
• 9.3 Add a setup/catalog packet that covers proven connector addability, multiple accounts, owner naming, exact scopes/prerequisites, provider validation, honest unavailable states, and live first-sync status.
• 9.4 Add a source-inventory packet that covers status legends, count basis labels, rollup drill-through, source detail as a first-class destination, and hidden/tombstoned retired streams.
• 9.5 Add a recovery packet that covers one human cause, one closing action, live progress, terminal reconciliation, and scoped diagnostics.
• 9.6 Add an access-review packet that covers client grouping, concrete grant scope, revocation, last-used/read facts, and client-filtered activity.
• 9.7 Add an evidence-timeline packet that covers subject-scoped entry, dense event grammar, filters, linked artifacts, overflow-free layouts, and raw payload detail as supporting evidence.
• 9.8 Add a craft packet that covers row affordances, selected/focus state spacing, desktop/mobile layout, transition behavior, and purposeful motion.
• 9.9 Add a fresh-owner onboarding packet that covers readiness, deployment-setting prerequisites, first source setup, first records, and first AI-client grant.
• 9.10 Fix the Amazon browser setup credential-boundary regression: connection-scoped browser setup must not satisfy a new source by consuming deployment-wide Amazon credentials.
• 9.11 Capture the corrected source credential-mode contract: deployment-wide provider account credentials are forbidden, source-scoped stored credentials remain valid, streamed browser proof remains the default, and ephemeral cleanup requires explicit proof.
• 9.12 Stabilize the connector/runtime implementation so source-scoped credential helpers are preserved, deployment-wide provider account fallbacks fail closed, and tests prove cross-source credential reuse cannot occur.
• 9.13 Make supported browser-backed provider setup credential-first and source-scoped: manifests declare username/password capture, the default Add Data path uses /dashboard/records/add/static-secret/..., capture seals a per-source bundle, and successful capture starts source-scoped setup status instead of reporting vague setup success.
• 9.14 Make browser-backed credential setup mode-explicit: the shared setup surface presents stored source credentials as reusable assistance after browser-session expiry and preserves a browser-only path for owners who do not want provider credentials stored.
• 9.15 Make stored-credential browser-backed setup interruption-aware: after credential capture the owner lands on durable setup status, first collection starts quietly, and the secure browser CTA appears only when the existing run interaction machinery reports a current owner-required login, OTP, challenge, or identity confirmation.
• 9.16 Scope Add source/setup read failures to a setup-specific error boundary so setup routes do not render the parent Sources-list refresh fallback.
• 9.17 Make the owner connector-summary route list/detail coherent for multi-account connectors by hydrating run-backed verdict evidence instead of using singleton-only shallow run mode.
• 9.18 Make browser-backed setup stream pages connection-scoped and progress-aware: when a setup run is already collecting, the owner sees the exact source and latest progress instead of a stale preparing-browser state or another account with the same connector type.