# Fable 5 xhigh review + Opus 5 xhigh implementation prompt — cross-channel conversation workspace

You are the lead implementation controller for the `petav3` Laravel/Inertia/Vue
repository. Execute the approved cross-channel conversation-workspace plan from
start to finish. Do not merely review it and do not stop after drafting code.

## Runtime and workspace

- The lead controller and every read-only reviewer must run as **Fable 5 with effort xhigh**.
- Every code implementer and code fixer must run as **Opus 5 with effort xhigh**.
- Do not substitute another model or lower the effort level when either model is unavailable; pause and report the exact availability or quota error instead.
- Work only in:
  `/Users/dadadineiyou/Documents/GitHub/petav3-dev-chen-integration`
- The checked-out target branch is local `dev-chen`.
- Do not push, open a PR, deploy, or enable production feature flags during
  implementation. Task 11 authorizes pushing `dev-chen` and opening a ready PR
  only after every release gate is persisted off and all final reviews pass.
- Do not switch to another repository/worktree.
- Do not create an artificial elapsed-time goal. If a stale `/goal` exists,
  clear it before starting; completion is defined only by the plan's acceptance
  criteria and verification evidence.

## Read first — authoritative inputs

Read these files completely, in this order:

1. `/Users/dadadineiyou/Documents/GitHub/petav3-dev-chen-integration/AGENTS.md`
2. `/Users/dadadineiyou/Documents/GitHub/petav3-dev-chen-integration/docs/superpowers/specs/2026-08-14-cross-channel-conversation-workspace-design.md`
3. `/Users/dadadineiyou/Documents/GitHub/petav3-dev-chen-integration/docs/superpowers/plans/2026-08-14-cross-channel-conversation-workspace-implementation.md`
4. `/Users/dadadineiyou/.codex/skills/subagent-driven-development/SKILL.md`
5. `/Users/dadadineiyou/.codex/skills/test-driven-development/SKILL.md`
6. `/Users/dadadineiyou/.codex/skills/requesting-code-review/SKILL.md`
7. `/Users/dadadineiyou/.codex/skills/finishing-a-development-branch/SKILL.md`

The original cross-channel design passed two Fable 5 High architecture reviews.
Task 11's database-backed release controls and PR handoff were added afterward.
Before Task 1, dispatch one independent Fable 5 xhigh read-only architecture,
authorization, and operability review focused on the amended design/plan diff.
Resolve and re-review every Critical/Important finding before any Opus
implementer starts. If code evidence contradicts the plan, do not silently
choose: record the exact contradiction, assess whether it is safely resolvable
without changing product intent, and stop only if a real user decision is
unavoidable.

## Preflight

1. Confirm branch and worktree with `git status --short --branch`.
2. The tree must be clean. If it is dirty, inspect exactly what is changed and
   stop rather than overwrite unrelated work.
3. Create a recoverable backup ref at the current HEAD:
   `refs/backup/dev-chen-pre-cross-channel-conversation-workspace`.
4. Record the starting commit and current test baseline before Task 1.
5. Check `.superpowers/sdd/progress.md`; if it exists, trust completed task
   commits and resume at the first incomplete task. Never redo a completed task.
6. Do not initialize CodeGraph in this worktree without asking. Native `rg` and
   file reads are acceptable here.

## Required execution method

Use **subagent-driven development** continuously through all 11 tasks.

For every task, in order:

1. Use the task-brief helper from the subagent-driven-development skill to
   extract only that task into a unique brief file.
2. Dispatch a **fresh Opus 5 xhigh implementer subagent**. Give it the brief,
   exact prerequisite interfaces already committed by earlier tasks, the report
   path, and the global constraints. Tell it other agents may have edited the
   repository and it must preserve their work.
3. The implementer must use test-driven development: failing test first,
   observed failure, minimal implementation, focused passing tests, self-review,
   one or more atomic conventional commits, and a report containing commands and
   exact results.
4. Generate a review package from the task's recorded base commit to its head.
5. Dispatch a fresh **specification-compliance reviewer** and a separate fresh
   **code-quality/security reviewer**, both Fable 5 xhigh. They read the brief,
   implementer report, and review package. They do not edit.
6. If either reviewer reports Critical/Important issues, dispatch one fresh
   Opus 5 xhigh fixer with the complete finding list. It must run the covering
   tests and append evidence to the task report. Re-run both reviews. Do not
   proceed while any Critical/Important issue remains.
7. Append the clean task result and commit range to
   `.superpowers/sdd/progress.md`.
8. Continue automatically to the next task. Do not ask “should I continue?”.

Implementation subagents run **sequentially**, never in parallel, because the
tasks share migrations, models, routes, and Vue components. Independent review
subagents may run in parallel after a task implementation is complete.

## Binding engineering constraints

- Implement the plan exactly; no speculative functionality.
- Preserve the existing Zoom public behavior and compatibility routes.
- Migration order is load-bearing:
  1. additive nullable expansion + deterministic Zoom backfill;
  2. make every create/restore/update path dual-write;
  3. only then run preflighted NOT NULL + composite unique tightening.
- Never allow manual null-plan action items into `SalesWorkQueue`.
- Never persist a provenance URL. Compute it per viewer only after source
  authorization.
- Super Admin may review/approve all team plans and pipeline matches; ordinary
  users see only assigned-to-self checklist tasks.
- Preserve current source-view boundaries: Zoom LeadVisibility, Call VIEW_CALLS,
  Showroom VIEW_F2F.
- AI suggestion and human confirmation remain separate columns/states.
- Product and commission come only from a confirmed Lead-owned Engagement and
  `EngagementOpportunityValue`; do not join the bookings has-many relation.
- Ask AI provider context is allow-listed, bounded, and protected by
  `<RECORDING_CONTEXT>` plus `JSON_HEX_TAG`. No phone, contact, ASR provider JSON,
  media URL, credentials, imported lineage, or Chinese duplicate analysis.
- Enter sends; Shift+Enter adds a newline; IME/composition Enter and keyCode 229
  do not send; rapid Enter cannot duplicate a request.
- Phone, Showroom, and Zoom tasks for the same Lead group together in the one
  Sales Dashboard/Action Items checklist, with source provenance on each task.
- Do not add conversion probability, claimed uplift, automatic approval,
  automatic pipeline confirmation, or separate Call/F2F task dashboards.
- The four release gates (Action Plans / Checklist, recording Ask AI,
  Pipeline Product / Commission, and Lead Sales Coach) must be controlled from
  the existing Super Admin AI settings UI through the database. Missing or
  malformed values mean false. Old environment flags must not be required or
  honored by the final runtime resolver.
- Keep GET requests read-only.
- Keep every row-lock, transaction, restore-under-lock, soft-delete, and unique
  idempotency invariant already tested by Zoom.
- Use `apply_patch` for manual file edits. Do not run destructive git commands.

## Review requirements by risk

In addition to the two per-task reviewers:

- Migration/repository tasks must include database/concurrency scrutiny and
  mutation evidence for `lockForUpdate()` and identity uniqueness.
- Ask AI tasks must include authorization/privacy/prompt-injection scrutiny and
  a mutation that proves removing `JSON_HEX_TAG` breaks the test.
- Vue workspace tasks must include lifecycle, source-swap, independent-scroll,
  mobile ordering, keyboard, IME, accessibility, and build review.
- SalesWorkQueue tasks must include query-count/N+1, Lead pagination, assignment
  scoping, no-contact team payload, and unauthorized source-URL review.

## Final gate after Task 11

Create one full review package from the preflight start commit to HEAD. Dispatch
five independent Fable 5 xhigh read-only reviewers:

1. architecture/integration compatibility;
2. authorization/privacy/security;
3. database migrations/concurrency/idempotency;
4. Vue UX/accessibility/state lifecycle;
5. test quality and regression coverage.

Give all five the design, plan, full review package, and verification report.
Consolidate their findings. If any Critical/Important issue exists, dispatch one
coordinated Opus 5 xhigh fixer for the complete list, run the covering suites, regenerate the
package, and re-run the affected reviews until clean.

Then run and record:

```bash
vendor/bin/pint --test
herd php artisan test
npm test
npm run build
git diff --check
php scripts/check-migration-constants.php
```

If the full PHP suite has known baseline failures, compare test names one by one
against the preflight baseline and prove there are zero new regressions; do not
call a failure “pre-existing” without evidence.

Perform the full browser walkthrough on `https://petav3.test` for Zoom, Phone
Call, and Showroom as Super Admin, then the visibility-sensitive checks as
ordinary Admin/Sales. Use actual UI actions and inspect failed network responses;
do not rely only on screenshots. Verify literal feature flag `false` in the
running app. Do not consume the only demo draft without restoring a repeatable
demo state.

## Completion report

Finish only when all 11 task reviews and the final gate are clean. Report:

- final `dev-chen` commit;
- ordered list of task commits;
- migration up/down and post-cross-channel rollback-refusal evidence;
- focused and full test/build results;
- browser walkthrough results for all roles/channels;
- final reviewer verdicts and resolved findings;
- feature-flag state;
- evidence that all four database-backed release gates are on after the release
  migration and can still be withdrawn or restored from the Super Admin UI
  without an environment change;
- backup ref;
- pushed branch and ready PR URL (but confirmation that nothing was deployed or
  merged);
- any remaining known limitations explicitly allowed by the design.

Do not reset or squash the atomic task commits. Push and open the PR only at the
end of Task 11 after the release gate is clean.
