# Watchdog Issue #1111 / #1112 / #1124 Case Closure Plan

## Goal

This document defines the minimum case expansion needed so the current watchdog
system can credibly cover the problem surfaces described by:

1. `#1111` overall staging regression rollup
2. `#1112` field / label / overlay delta audit
3. `#1124` quote / contract / order environment blocker rollup

The purpose is not to inflate raw case count. The purpose is to close the
largest current proof gaps:

1. schema / describe contract gaps
2. readiness / fixture existence gaps
3. browser-only UX behavior gaps

## Current Baseline

Current API watchdog inventory:

1. `11` scenes
2. `53` executable API cases

Current API watchdog can already detect:

1. many downstream seed / readiness gaps
2. major quote / approval / order fixture failures
3. several auth, lead, campaign, opportunity, and admin regressions

Current API watchdog cannot yet fully cover:

1. object describe / field-label / overlay-shape drift from `#1112`
2. browser-only UI behaviors called out in `#1111`
3. several explicit readiness blockers behind `#1124`

## Coverage Judgment By Issue

### `#1111`

Current `53` API cases cover only part of `#1111`.

Covered well:

1. product / quote / order fixture existence
2. approval / security / reporting / integration readiness gaps
3. some business-path CRUD and persistence proof

Not fully covered:

1. stage-path UI refresh behavior
2. delete confirmation copy / recycle-bin wording
3. weekly-update option visibility in UI
4. sub-tabs / action buttons / list views / clone UX
5. global search page behavior

Conclusion:

1. `#1111` needs both API and browser lanes
2. do not try to force it into API-only closure

### `#1112`

Current `53` API cases only cover `#1112` indirectly.

Missing proof types:

1. object describe field count
2. key field existence
3. label parity
4. default value parity
5. record-type / metadata shape parity

Conclusion:

1. `#1112` requires explicit describe-contract cases
2. overlay readiness alone is insufficient

### `#1124`

Current `53` API cases cover most of the main path of `#1124`, but not all.

Already represented:

1. `product-catalog-readiness-api`
2. `quote-order-fixture-readiness-api`
3. `quote-create-api`
4. `quote-line-items-api`
5. `quote-approval-submit-api`
6. `approval-submit-tab-api`
7. `order-create-api`
8. `contract-management-api`

Still missing or too implicit:

1. explicit order-record-type readiness proof
2. explicit approval-definition readiness proof
3. archived upload UX flows
4. approval submit / recall browser flow

Conclusion:

1. `#1124` is close to case-coverage closure
2. it still needs a small readiness-case expansion plus browser cases

## Required New Cases

## A. New API Cases

These are the minimum additional API cases required.

### Priority P0

1. `campaign-describe-contract-api`
   - target issues: `#1112`, `#1111`
   - prove:
     - `Campaign.CurrencyIsoCode` exists or is intentionally absent
     - `Campaign.OwnerId` label contract
     - key business fields expected from downstream overlay
   - gate type:
     - schema / overlay parity

2. `lead-describe-contract-api`
   - target issues: `#1112`, `#1111`
   - prove:
     - key converted fields exist
     - label deltas on `Rating`, `PostalCode`, `State`
     - selected PingCAP overlay fields exist
   - gate type:
     - schema / overlay parity

3. `order-recordtype-readiness-api`
   - target issues: `#1124`
   - prove:
     - order record types exist
     - actor can access the intended record type
     - create flow is not blocked by record-type absence
   - gate type:
     - readiness / fixture contract

4. `approval-definition-readiness-api`
   - target issues: `#1124`, `#1111`
   - prove:
     - at least one active Quote-targeted approval definition exists
     - submit actor can see or invoke submission path
     - approver path is wired
   - gate type:
     - readiness / env contract

### Priority P1

5. `campaign-member-describe-contract-api`
   - target issues: `#1112`
   - prove:
     - key standard and overlay field presence
     - stable shared-label contract

6. `campaign-member-status-describe-contract-api`
   - target issues: `#1112`
   - prove:
     - `Name` field contract
     - owner / modifier label shape

7. `security-bootstrap-readiness-detail-api`
   - target issues: `#1111`
   - prove:
     - contrasted actors really exist
     - role / permset / assignment path is present before scene execution

8. `reporting-definition-readiness-api`
   - target issues: `#1111`
   - prove:
     - report / dashboard fixtures exist in the target environment
     - the scene is blocked by real business defect, not missing setup

### Priority P2

9. `integration-webhook-readiness-api`
   - target issues: `#1111`
   - prove:
     - downstream integration config exists
     - sync test is blocked by runtime contract only if config is present

## B. New Browser Cases

These should stay in the browser watchdog lane.

### Priority P0

1. `quote-approval-submit-recall-browser`
   - target issues: `#1124`, `#1111`
   - prove:
     - submit button exists
     - pending state is visible
     - recall path is visible and functional if in scope

2. `contract-upload-archived-file-browser`
   - target issues: `#1124`
   - prove:
     - approved-to-effective upload flow
     - button visibility by status
     - file appears in Files tab

3. `order-upload-archived-form-browser`
   - target issues: `#1124`
   - prove:
     - order creation path reaches upload step
     - archived form upload is exposed and persisted

### Priority P1

4. `weekly-update-ui-behavior-browser`
   - target issues: `#1111`
   - prove:
     - UI exposes Weekly Update action / type where required

5. `delete-recycle-bin-copy-browser`
   - target issues: `#1111`
   - prove:
     - delete confirmation wording matches recoverability contract

6. `opportunity-subtabs-actions-browser`
   - target issues: `#1111`
   - prove:
     - downstream subtabs and PingCAP action buttons are actually rendered

## Mapping: New Case -> Existing Gap

| New Case | Primary Gap Type | Main Issue(s) | Why Current `53` Are Not Enough |
| --- | --- | --- | --- |
| `campaign-describe-contract-api` | schema parity | `#1112` | current cases use behavior as proxy; no direct describe proof |
| `lead-describe-contract-api` | schema parity | `#1112` | current cases do not verify field-shape contract |
| `campaign-member-describe-contract-api` | schema parity | `#1112` | current campaign cases do not assert member describe shape |
| `campaign-member-status-describe-contract-api` | schema parity | `#1112` | current cases do not isolate member-status describe drift |
| `order-recordtype-readiness-api` | readiness | `#1124` | current failures are indirect and harder to triage |
| `approval-definition-readiness-api` | readiness | `#1124`, `#1111` | current submit failures mix env and business defects |
| `security-bootstrap-readiness-detail-api` | readiness | `#1111` | current scene skip is too coarse |
| `reporting-definition-readiness-api` | readiness | `#1111` | current reporting skip is too coarse |
| `integration-webhook-readiness-api` | readiness | `#1111` | current integration skip is too coarse |
| browser approval/upload/UX cases | browser proof | `#1111`, `#1124` | API lane cannot prove UI affordance and workflow visibility |

## Coverage Matrix

This is the execution backlog view of the required additions.

| Item | Lane | Scene | Main Issue(s) | Blocker Type | Priority | Dependency | Intended Outcome |
| --- | --- | --- | --- | --- | --- | --- | --- |
| `campaign-describe-contract-api` | API | `campaign` | `#1112`, `#1111` | overlay/schema drift | P0 | overlay verify inputs | executable Campaign describe parity proof |
| `lead-describe-contract-api` | API | `lead` | `#1112`, `#1111` | overlay/schema drift | P0 | overlay verify inputs | executable Lead describe parity proof |
| `order-recordtype-readiness-api` | API | `quote-approval-order-contract` | `#1124` | env metadata | P0 | order metadata closure | direct proof that Order path is blocked or unblocked by record type |
| `approval-definition-readiness-api` | API | `quote-approval-order-contract` | `#1124`, `#1111` | env approval config | P0 | approval env closure | direct proof that approval submit path is blocked or unblocked by definition/actor |
| `quote-approval-submit-recall-browser` | browser | `quote-approval-order-contract` | `#1124`, `#1111` | UI workflow | P0 | approval env closure | visible submit / pending / recall proof |
| `contract-upload-archived-file-browser` | browser | `quote-approval-order-contract` | `#1124` | UI workflow | P0 | quote/order baseline graph | visible upload flow proof on Contract |
| `order-upload-archived-form-browser` | browser | `quote-approval-order-contract` | `#1124` | UI workflow | P0 | order metadata closure | visible upload flow proof on Order |
| `campaign-member-describe-contract-api` | API | `campaign` | `#1112` | overlay/schema drift | P1 | overlay verify inputs | explicit CampaignMember parity proof |
| `campaign-member-status-describe-contract-api` | API | `campaign` | `#1112` | overlay/schema drift | P1 | overlay verify inputs | explicit CampaignMemberStatus parity proof |
| `security-bootstrap-readiness-detail-api` | API | `security-and-visibility` | `#1111` | env bootstrap | P1 | security actor closure | converts coarse skip into exact missing bootstrap bucket |
| `reporting-definition-readiness-api` | API | `reports-dashboards` | `#1111` | env bootstrap | P1 | reporting fixture closure | converts coarse skip into exact reporting blocker |
| `weekly-update-ui-behavior-browser` | browser | `opportunity` | `#1111` | UI behavior | P1 | overlay verify inputs | proves weekly-update action/type visibility |
| `delete-recycle-bin-copy-browser` | browser | `opportunity` | `#1111` | UI copy/behavior | P1 | none | proves delete confirmation wording contract |
| `opportunity-subtabs-actions-browser` | browser | `opportunity` | `#1111` | UI overlay rendering | P1 | overlay verify inputs | proves subtabs and business actions render |
| `integration-webhook-readiness-api` | API | `integration` | `#1111` | env bootstrap | P2 | integration config closure | converts integration skip into exact config blocker |

## Suggested Slice Order

These are the recommended execution slices, not just topic groups.

### Slice 1: Quote / Approval / Order unblock

1. `order-recordtype-readiness-api`
2. `approval-definition-readiness-api`
3. `quote-approval-submit-recall-browser`

Reason:

1. directly closes the biggest ambiguity from `#1124`
2. aligns with the highest-value currently failing scene

### Slice 2: Describe parity proof

1. `campaign-describe-contract-api`
2. `lead-describe-contract-api`
3. `campaign-member-describe-contract-api`
4. `campaign-member-status-describe-contract-api`

Reason:

1. turns `#1112` into executable downstream proof
2. creates reusable overlay verify inputs for deploy readiness

### Slice 3: Browser-only `#1111` gaps

1. `weekly-update-ui-behavior-browser`
2. `delete-recycle-bin-copy-browser`
3. `opportunity-subtabs-actions-browser`

Reason:

1. API lane cannot replace these
2. they must exist if we claim `#1111` is watchdog-covered

### Slice 4: Coarse skip refinement

1. `security-bootstrap-readiness-detail-api`
2. `reporting-definition-readiness-api`
3. `integration-webhook-readiness-api`

Reason:

1. prevents large skipped buckets from hiding under one label
2. feeds the env-contract closure plan directly

## Cross-Link To Env Closure

This case plan depends on:

1. [watchdog-downstream-env-contract-closure-plan.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/exec-watchdog-issue-1111-1112-1124-plan/docs/watchdog-downstream-env-contract-closure-plan.md)

That companion document defines how to close the downstream env contract so the
new cases fail for meaningful reasons instead of setup noise.

## Non-Goals

Do not add more generic CRUD cases just to increase count.

This plan explicitly avoids:

1. duplicating existing lead / opportunity / campaign persistence coverage
2. adding more API cases that only restate a failing scene-level contract
3. trying to replace browser cases with API assertions

## Execution Order

### Wave 1: Direct coverage gaps for `#1124`

1. `order-recordtype-readiness-api`
2. `approval-definition-readiness-api`
3. `quote-approval-submit-recall-browser`
4. `contract-upload-archived-file-browser`
5. `order-upload-archived-form-browser`

Reason:

1. shortest path to close the quote / approval / order / contract ambiguity
2. highest leverage against currently failing quote-order readiness

### Wave 2: Explicit parity proof for `#1112`

1. `campaign-describe-contract-api`
2. `lead-describe-contract-api`
3. `campaign-member-describe-contract-api`
4. `campaign-member-status-describe-contract-api`

Reason:

1. turns `#1112` from external audit evidence into repo-owned executable proof

### Wave 3: Browser-only `#1111` closure

1. `weekly-update-ui-behavior-browser`
2. `delete-recycle-bin-copy-browser`
3. `opportunity-subtabs-actions-browser`

Reason:

1. these are real regressions but API cases cannot prove them

### Wave 4: Coarse-scene skip refinement

1. `security-bootstrap-readiness-detail-api`
2. `reporting-definition-readiness-api`
3. `integration-webhook-readiness-api`

Reason:

1. converts large skipped buckets into concrete readiness blockers

## Done Definition

This case-closure plan is complete when all conditions hold:

1. every concern in `#1112` has at least one direct executable describe / metadata proof
2. every main blocker in `#1124` has a dedicated readiness or browser case
3. browser-only problems from `#1111` are represented in the browser watchdog lane
4. no remaining major concern from `#1111` / `#1112` / `#1124` is explained only by free-form issue comments

## Expected Outcome

After this expansion, the watchdog system should be able to say, for each of
the three issues:

1. this is covered by API contract proof
2. this is covered by browser proof
3. this is still intentionally uncovered and why

That is the minimum bar for claiming that watchdog coverage is aligned with
these three issue families.