# Claude review-and-implementation prompt

Copy everything below into Claude Code as one prompt.

```text
You are the lead implementation orchestrator for the local PETA V3 repository.

Repository / target:
- Repository: /Users/dadadineiyou/Documents/GitHub/petav3-dev-chen-integration
- Authoritative local target branch: dev-chen
- The local dev-chen intentionally contains unpublished work and may be ahead/behind origin. Do NOT pull, merge origin, reset, rebase, push, or open a PR.
- Final result must be integrated into local dev-chen only, by cherry-picking verified task commits from an isolated worktree/branch.

Your mission is to REVIEW the approved design and three implementation plans critically, correct them if necessary, and then IMPLEMENT the executable scope completely in this order:

1. docs/superpowers/specs/2026-08-06-ai-sales-follow-up-workspace-design.md
2. docs/superpowers/plans/2026-08-06-action-plan-workflow-hardening.md
3. docs/superpowers/plans/2026-08-06-zoom-opportunity-linkage-and-value.md
4. docs/superpowers/plans/2026-08-06-explainable-opportunity-prioritisation.md

Use these skills/work modes:
- Read AGENTS.md and every referenced SKILL.md completely before acting.
- Use superpowers:executing-plans as the execution discipline.
- Prefer superpowers:subagent-driven-development: one fresh implementation worker per task, followed by a spec-compliance reviewer and a code-quality reviewer.
- Use test-driven development for every behavior change.
- Use database, security, PHP and Vue/JavaScript specialist reviewers where relevant.

Critical-thinking rules for every agent and reviewer:
- Check for false premises, logical jumps, missing information and inconsistent contracts before agreeing.
- Distinguish verified code facts, inferences and product opinions.
- Verify numerical, commission, permission and data-model claims against the repository.
- State disagreements directly with evidence, risk and a safer alternative.
- Call out hidden variables, operating cost, latency, migration impact, privacy risk and selection bias.
- Do not turn meeting examples into product facts.

PHASE 0 — SAFE START

1. Run read-only checks first:
   - git status --short --branch
   - git log --oneline -15
   - git worktree list
   - confirm the four files above exist
2. If the dev-chen worktree is dirty, STOP and report exact paths; do not overwrite user changes.
3. Create a recoverable backup ref at the current local dev-chen HEAD.
4. Create an isolated worktree/branch from the CURRENT LOCAL dev-chen, not origin/dev-chen. Suggested branch: claude/ai-sales-follow-up-workspace.
5. Never read or print secrets. Do not commit .env, local databases, transcripts, customer PII, screenshots, AI responses or browser artifacts.

PHASE 1 — INDEPENDENT PLAN REVIEW BEFORE CODE

Spawn parallel bounded reviewers with non-overlapping responsibilities:

A. Architecture/data-model reviewer
- Verify JSON-vs-normalized boundaries, migration reversibility, integer constants, relationship cardinality, idempotency and lifecycle behavior.

B. Product/AI-logic reviewer
- Verify that AI suggestion vs human decision stays separate, no false conversion probabilities/uplift enter the product, and action/intent/confidence terminology is honest.

C. Backend/security reviewer
- Verify feature-flag invisibility, Super Admin/Sales authorization, LeadVisibility on every read/write, AI UUID allow-lists, prompt-injection boundaries and no partial approval writes.

D. Frontend/UX/accessibility reviewer
- Verify per-step assignment/priority usability, explicit Apply Proposal behavior, role-based checklist views, contact-action safety and accessible states.

E. Test/integration/performance reviewer
- Verify the plan has behavioral tests for legacy compatibility, concurrent approval, pagination/order stability, N+1/query cost, migration round trips and flag-off states.

Every reviewer must cite exact files/lines and classify findings P0/P1/P2/P3. They must not edit code.

Consolidate the findings yourself. Do not rubber-stamp them. If a finding is correct:
- update the design/plan docs first;
- run a second focused review of the corrected contract;
- only begin code when no P0/P1 design finding remains.

Ask the user only if a missing choice would materially change product behavior and cannot be resolved by the approved spec. Otherwise use the spec's declared decisions. In particular, these are already decided:
- no due dates in this release;
- visible name is My Checklist / Current Tasks;
- no automatic approval, assignment, contact, Pipeline mutation or prompt tuning;
- no request-rate limit in this scope;
- new demo prompt keys are pinned locally through the existing AI Prompt settings to OpenAI gpt-5.6-terra, never hard-coded in controllers and never committed as local database state;
- no hard-coded 5% analyst incentive;
- no precise conversion probability or expected uplift;
- production flags default false;
- no push/PR.

PHASE 2 — IMPLEMENT PLAN A TASK BY TASK

Execute docs/superpowers/plans/2026-08-06-action-plan-workflow-hardening.md in order.

For each task:
1. Create/update a tracked task entry.
2. Assign one implementation worker explicit ownership of only that task's files. Tell it other agents share the codebase and it must not revert others' changes.
3. Worker writes failing tests first, proves the intended failure, writes the minimum implementation, runs focused tests and commits one logical concern.
4. Run a fresh spec-compliance reviewer against the task contract.
5. Run a fresh code reviewer; add database/security/Vue specialists when relevant.
6. Fix every valid P0/P1 and justified P2 finding.
7. Rerun the task's tests and record exact pass evidence before moving on.

Do not run multiple implementation workers against overlapping files simultaneously. Parallelize read-only reviews and independent verification, not conflicting edits.

After Plan A, run its complete Task 10 verification and manually rehearse on petav3.test. Do not start Plan B while Plan A has a regression or unresolved P0/P1.

PHASE 3 — IMPLEMENT PLAN B

Execute docs/superpowers/plans/2026-08-06-zoom-opportunity-linkage-and-value.md with the same implement → spec review → code/security/database review → fix → verify gates.

Non-negotiable checks:
- The AI only sees and may return server-listed Engagement UUIDs for the linked Lead.
- A model response never confirms or mutates Pipeline data.
- Confirmation is a locked Super Admin write with current membership revalidation.
- Commission output exactly matches existing Booking/Project rules for the same Engagement.
- Unknown commission is null/Unknown, never RM0.
- Suggested-only projects are labelled Needs review, never presented as confirmed facts.

PHASE 4 — IMPLEMENT PLAN C

Execute docs/superpowers/plans/2026-08-06-explainable-opportunity-prioritisation.md with the same gates.

Reject any implementation that:
- outputs a conversion percentage, likelihood percentage or action uplift;
- treats data confidence as buying likelihood;
- uses meeting duration as a decisive score;
- sorts a paginated page in PHP;
- duplicates ranking logic between Zoom and Dashboard;
- presents missing commercial value as zero.

The Deferred Evidence Gate at the end of Plan C is NOT code to implement. It is a hard product boundary. Stop at explainable signals and data relationships.

PHASE 5 — MANDATORY FINAL VERIFICATION

Run, at minimum:

1. Every focused PHP suite listed in the three plans.
2. npm test
3. npm run build, including SSR if that script does both.
4. Pint on all changed PHP files; do not reformat unrelated files.
5. Scratch-database migration up and down for every new migration.
6. Feature-flag off tests for every route/prop/UI entry.
7. Authorization tests for Super Admin, assigned Sales, unrelated Sales and lost Lead visibility.
8. Idempotent/concurrent Action Plan approval tests.
9. N+1/query-count and stable-pagination tests for Team Tasks and opportunity ordering.
10. Browser rehearsal on petav3.test of the complete acceptance journey in the design spec.

If a broad suite fails, determine whether it is new. A failure may be called pre-existing only after reproducing it at the clean base commit/worktree. Do not weaken or delete tests to make the build green.

Run final parallel reviewers:
- integration reviewer across all three plans;
- security reviewer;
- database/migration/performance reviewer;
- Vue/UX/accessibility reviewer;
- silent-failure/error-propagation reviewer;
- product-logic reviewer checking every score/value/label claim.

Fix valid findings and rerun affected verification.

PHASE 6 — LOCAL INTEGRATION AND REPORT

1. Ensure the implementation worktree and target dev-chen worktree are clean.
2. Confirm the backup ref exists.
3. Cherry-pick only the task commits, in dependency order, into local dev-chen.
4. Resolve conflicts only when unambiguous. If target worktree is dirty or conflict meaning is unclear, STOP and report; never overwrite.
5. Rerun the focused smoke suites on integrated dev-chen.
6. Do not push and do not create a PR.

Final response must include:
- outcome first;
- exact commits integrated into local dev-chen;
- concise feature summary by Plan A/B/C;
- verification commands and pass/fail counts;
- any proven pre-existing failures separately;
- migration up/down evidence;
- browser rehearsal results;
- feature-flag state;
- remaining product limitations, especially the probability/uplift evidence gate;
- confirmation that no secrets/PII/env/database artifacts were committed.

Do not stop after planning or review. Continue through implementation, reviews, fixes, verification and local dev-chen integration unless there is a real safety blocker under the rules above.
```