# Local API 1118 Verification Report

Updated: `2026-05-08`
Latest refresh: `2026-05-10`

## Latest/Latest Refresh

Latest targeted recheck used:

1. downstream `origin/main`: `b01bb6f6be548698a975d3821bc355210fd1ea1a`
2. upstream `origin/main`: `2526ced686cf43eaf8b3e1676ec2cefaa7e8f7ac`

Current latest/latest signal:

1. `overlay-readiness-api`
   - `passed`
2. `approval-definition-readiness-api`
   - `infra_error`
   - current blocker is no longer just missing downstream fixture
   - `ProcessDefinition` seed/query/create path now maps to upstream runtime blocker `#1192`
3. `reporting-definition-readiness-api`
   - `blocked`
   - shallow blocker is stale `DashboardFolder` query contract
   - deeper blocker is upstream runtime inability to materialize `Report` / `Dashboard` through generic sObject path
   - tracked in `#1194`
4. `security-bootstrap-readiness-api`
   - `infra_error`
   - current failure edge is `PermissionSetAssignment` create path, not simply “missing contrasted users”
5. `users-roles-sharing-admin-api`
   - `failed`
   - `UserRole` and `Group` create succeed
   - `GroupMember` create fails on runtime key-prefix handling
6. `integration-pack-readiness-api`
   - still `skipped`
   - direct `_System_Webhook` probe suggests the same setup-object runtime create-path gap if downstream fixture materialization is attempted through generic API

## Current Rerun Blocker

Fresh local rerun is currently blocked by a local auth drift:

1. local watchdog services are healthy on `http://127.0.0.1:5177` and `http://127.0.0.1:3103`
2. but password-grant login for `admin@example.invalid` and the other watchdog actors is currently returning `invalid_grant`
3. this blocks a new end-to-end replay of the latest strengthened cases until local credentials are re-aligned

## Scope

This report captures local verification after:

1. expanding API watchdog coverage for the `#1118` gap line
2. fixing local bootstrap blockers in the downstream pack
3. running the new and strengthened API scenes against the local stack

Local target:

- frontend: `http://127.0.0.1:5177`
- backend: `http://127.0.0.1:3103`

## Local Bootstrap Fixes Needed First

The local stack did not boot cleanly on current `origin/main` shape until two downstream pack issues were fixed:

1. `Campaign.OwnerId` and `Opportunity.OwnerId` were incorrectly redeclared in:
   - [packs/Salesforce-PingCAP-L2/objects/Campaign.json](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/packs/Salesforce-PingCAP-L2/objects/Campaign.json)
   - [packs/Salesforce-PingCAP-L2/objects/Opportunity.json](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/packs/Salesforce-PingCAP-L2/objects/Opportunity.json)
2. the downstream audit script still enforced the old assumption that `Campaign.OwnerId` must be present in final L1 spec:
   - [scripts/audit_final_pack_metadata.py](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/scripts/audit_final_pack_metadata.py)
3. the curated Campaign layout had to be aligned with runtime backfill output:
   - [packs/Salesforce-PingCAP-L2/layouts/campaign_page_layout.json](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/packs/Salesforce-PingCAP-L2/layouts/campaign_page_layout.json)

After those fixes, the then-current monolith local-site bootstrap completed and
local services became healthy. That retired bootstrap is historical context for
this report, not the current local D3 operator path.

## New / Strengthened Coverage Added

New cases:

1. `readiness/approval-readiness-api`
2. `readiness/product-catalog-readiness-api`
3. `readiness/quote-order-fixture-readiness-api`
4. `readiness/security-bootstrap-readiness-api`
5. `readiness/reporting-readiness-api`
6. `readiness/integration-pack-readiness-api`
7. `readiness/overlay-readiness-api`
8. `login-auth/oauth-userinfo-claims-api`
9. `security-and-visibility/effective-access-contrast-api`
10. `login-auth/oauth-revoke-contract-api`
11. `login-auth/oauth-authorize-parity-api`
12. `security-and-visibility/external-id-upsert-security-api`
13. `security-and-visibility/nested-groups-effective-access-api`
14. `setup-admin-metadata/custom-object-ddl-create-api`
15. `setup-admin-metadata/sharing-rule-contract-api`

Strengthened cases:

1. `campaign-list-customize-api`
   - now asserts `CurrencyIsoCode`
2. `campaign-create-edit-api`
   - now writes and re-reads `CurrencyIsoCode`
3. `campaign-member-status-admin-api`
   - now asserts the default-status flag
4. `lead-admin-config-api`
   - now pins `_System_RecordType`, `PageLayout`, `LayoutAssignment`, and `FlowDefinition`
5. `opportunity-field-updates-api`
   - now pins patched business fields plus stable header/business fields
6. `opportunity-tabs-actions-api`
   - now pins quote header shape and related `QuoteLineItem` shape
7. `approval-submit-tab-api`
   - now exercises Salesforce-style `requests[]` submit and latest-instance readback
8. `quote-approval-submit-api`
   - now pins legacy flat-body `ObjectApiName` / `RecordId` compatibility

Execution isolation changes:

1. API watchdog seed application is now bucket-scoped per selected case
2. scene execution now seeds and executes each API case independently before aggregating the report
3. this prevents one seed/runtime defect from collapsing unrelated readiness cases into one shared `infra_error`

Coverage posture after the latest case deepening:

1. case presence coverage for `#1118`: `100.0%`
2. strict case-level coverage for `#1118`: `100.0%`
3. fresh local rerun of the new deepened cases: pending local login fix

## Local Run Results

### `login-auth`

Run:

- `local-1118-auth-v2`
- `local-1118-oauth-revoke-v1`
- `local-1118-oauth-authorize-v1`
- report: [.runtime/watchdog/runs/api/local-1118-auth-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-auth-v2/report.md)
  - [.runtime/watchdog/runs/api/local-1118-oauth-revoke-v1/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-oauth-revoke-v1/report.md)
  - [.runtime/watchdog/runs/api/local-1118-oauth-authorize-v1/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-oauth-authorize-v1/report.md)

Evidence:

1. `oauth-userinfo-claims-api`
   - `passed`
   - confirms current `userinfo` payload contains the minimum claims now asserted
2. `oauth-compatibility-api`
   - `failed`
   - message: `missing refresh token from step: login-sales-user`
   - conclusion: password grant still does not satisfy refresh-token compatibility
3. `oauth-revoke-contract-api`
   - `failed`
   - message: `assertion valid-revoke-status expected status 200 but got 403`
   - conclusion: revoke path currently returns a direct contract failure
4. `oauth-authorize-parity-api`
   - `passed`
   - conclusion: authorize endpoint route and basic validation path are now directly covered

### `campaign`

Run:

- `local-1118-campaign-v1`
- report: [.runtime/watchdog/runs/api/local-1118-campaign-v1/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-campaign-v1/report.md)

Result:

- passed: `3`
- blocked: `1`

Evidence:

1. `campaign-list-customize-api`
   - `passed`
   - tightened run `local-1118-campaign-list-tighten-v2` now proves exact `Name`, `IsActive`, `Status`, and `CurrencyIsoCode`
2. `campaign-create-edit-api`
   - `passed`
   - proves create/edit plus `CurrencyIsoCode=USD` readback on the created campaign
3. `campaign-member-status-admin-api`
   - `passed`
   - proves default status flag is visible in current admin query path
4. `campaign-add-members-api`
   - `blocked`
   - message: `assertion create-campaign-member-status expected status 201 but got 400`
   - this is the known scoped-picklist / validator gap

### `security-and-visibility`

Run:

- `local-1118-security-v2`
- `local-1118-externalid-v1`
- `local-1118-nested-groups-v3`
- report: [.runtime/watchdog/runs/api/local-1118-security-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-security-v2/report.md)
  - [.runtime/watchdog/runs/api/local-1118-externalid-v1/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-externalid-v1/report.md)
  - [.runtime/watchdog/runs/api/local-1118-nested-groups-v3/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-nested-groups-v3/report.md)

Evidence:

1. `labels-validation-feedback-api`
   - `passed`
2. `activity-timeline-api`
   - `passed`
3. `security-effective-access-api`
   - `blocked`
   - message: `assertion visible-restricted-opportunity-found expected at least 1 records but got 0`
4. `effective-access-contrast-api`
   - `blocked`
   - message: `assertion visible-as-restricted-found expected at least 1 records but got 0`
5. `external-id-upsert-security-api`
   - `passed`
   - existing and missing external-id upsert paths were both handled without `404` / `500`
6. `nested-groups-effective-access-api`
   - `failed`
   - message: `assertion nested-group-member-created expected status 201 but got 500`
   - direct response shows `GroupMember.UserOrGroupId` is FK-constrained to `user`

Conclusion:

- the new contrast case is working as intended
- current local stack still lacks the contrasted security bootstrap / visibility fixtures that `#1118` needs
- external-id oracle probe is now present
- nested-group contract probe is now present and reproduces a backend defect

### `setup-admin-metadata`

Runs:

- `local-1118-custom-object-v1`
- `local-1118-sharing-rule-v3`
- `local-1118-users-roles-v2`
- `local-1118-permset-v2`
- reports:
  - [.runtime/watchdog/runs/api/local-1118-custom-object-v1/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-custom-object-v1/report.md)
  - [.runtime/watchdog/runs/api/local-1118-sharing-rule-v3/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-sharing-rule-v3/report.md)
  - [.runtime/watchdog/runs/api/local-1118-users-roles-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-users-roles-v2/report.md)
  - [.runtime/watchdog/runs/api/local-1118-permset-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-permset-v2/report.md)

Evidence:

1. `custom-object-ddl-create-api`
   - `passed`
   - custom object create + readback path is now directly covered
2. `sharing-rule-contract-api`
   - `failed`
   - message: `assertion sharing-rule-created expected status 201 but got 400`
   - direct response shows owner-based sharing rule create hits a contract-level validation defect
3. `users-roles-sharing-admin-api`
   - `passed`
   - role / group / group-member create+query path is now directly covered
4. `permission-set-admin-api`
   - `failed`
   - message: `assertion permission-set-group-created expected status 201 but got 400`
   - direct response shows `PermissionSetGroup` rejects the probed create contract while `PermissionSet` and assignment paths work

### `readiness`

Runs:

- `local-1118-readiness-v2`
- `local-1118-readiness-v3`
- `local-1118-readiness-v6`
- reports:
  - [.runtime/watchdog/runs/api/local-1118-readiness-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-readiness-v2/report.md)
  - [.runtime/watchdog/runs/api/local-1118-readiness-v3/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-readiness-v3/report.md)
  - [.runtime/watchdog/runs/api/local-1118-readiness-v6/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-readiness-v6/report.md)

Key findings:

1. `security-bootstrap-readiness-api`
   - `blocked` in `v2`
   - message: `assertion security-users-found expected at least 2 records but got 0`
   - confirms the missing contrasted security actor/bootstrap graph
2. later readiness reruns moved to `infra_error`
   - message: `failed to assign auto-numbers ... counter overflow ... QuoteLineItem`
   - this exposed a deeper runtime defect in the quote/line-item path that prevents stable readiness replay
3. after bucket-scoped per-case execution landed, `v6` separated the readiness scene into real case-level outcomes:
   - `product-catalog-readiness-api`: `passed`
   - `security-bootstrap-readiness-api`: `blocked` on missing contrasted users
   - `reporting-readiness-api`: `blocked` on missing `DashboardFolder`
   - `integration-pack-readiness-api`: `blocked` on missing `_System_ConnectedApp`
   - `overlay-readiness-api`: `blocked` on missing `PageLayout`
   - `approval-readiness-api`: `infra_error` on `QuoteLineItem` auto-number overflow
   - `quote-order-fixture-readiness-api`: `infra_error` on the same `QuoteLineItem` auto-number overflow

### `opportunity`

Runs:

- `local-1118-opportunity-v1`
- `local-1118-opportunity-v2`
- `local-1118-stage-tighten-v2`
- report:
  - [.runtime/watchdog/runs/api/local-1118-opportunity-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-opportunity-v2/report.md)
  - [.runtime/watchdog/runs/api/local-1118-stage-tighten-v2/report.md](/Users/bingwang/github/nexuscrm-pingcap-pack/.worktrees/api-1118-coverage-matrix/.runtime/watchdog/runs/api/local-1118-stage-tighten-v2/report.md)

Result:

- all `5` cases ended as `infra_error`

Shared error:

- `api POST /services/data/v63.0/sobjects/QuoteLineItem failed: 500`
- `failed to assign auto-numbers`
- `field counter 12 exceeds width=1 max=9`

Conclusion:

- the local stack currently has a reproducible runtime defect in the quote/line-item auto-number path
- this defect blocks deeper opportunity scene verification before story assertions are reached
- separately, the tightened stage-only probe now proves a direct story defect:
  - `opportunity-stage-progress-api` fails because `Probability` stays null after stage transition

## Bottom Line

The local process is now valid and useful:

1. bootstrap can complete after the downstream pack fixes
2. the new cases are executable and do surface current product/config/runtime gaps
3. the current local evidence now clearly separates:
   - auth compatibility defect
   - campaign member scoped-picklist defect
   - missing security/bootstrap graph
   - quote/line-item auto-number runtime defect