Beta RC Task Board and QA Plan

Reading guide

A dated assignment board and independent QA plan, including single-writer rules.

It preserves the work allocation of that wave; it is not a live issue tracker or current task status.

Baseline: 6c7e49908611b0e1975cedb1b862508625bde745

Control Plane task for this baseline document: cb8d07ca13c64b15b0793549abeedd9a (beta-rc-baseline, owner PRODUCT_DESIGN).

Single-writer assignments

Shared area	Single writer	Notes
be-cloudflare/src/lib.rs, auth_impl.rs, refund_impl.rs, events_impl.rs, settle_impl.rs	④ BACKEND_INFRA	Identity resolver and authorization fixes are serialized
be-cloudflare/src/public_impl.rs, endpoints_impl.rs, migrations	④ BACKEND_INFRA	Public/private and schema contracts
fe/lib/api/client.ts, fe/stores/db.ts, fe/middleware/**, fe/plugins/**	② PLATFORM_FE	FE foundation steward; ③ submits contract requests
fe/pages/settings/**, fe/pages/products/**, seller console pages	③ SELLER_FE	Seller workflow owner
fe/pages/admin/**, fe/pages/index.vue, signup.vue, login.vue, store/**, checkout/**, donate/**, license/**, legal/**	② PLATFORM_FE	Public and operator console owner
fe/e2e/**, fe/playwright.config.ts, scripts/verify-*.ps1	⑤ INDEPENDENT_QA	Independent test/evidence owner
docs/agent/**	PM / Tech Lead	Coordination and release record

Execution board

Issue	Epic	Owner	Priority	Status	Required evidence
RC-101	EP-01 Identity resolver	④-A	P0	READY	Worker role matrix + staging negative-auth evidence
RC-102	EP-01 Buyer/admin fallback removal	④-A	P0	READY	buyer subscription/refund/ff_retry/ledger negative tests
RC-103	EP-02 Public/private fail-closed	④-A	P0	READY	public store/widget/private DTO tests
RC-104	EP-03 FE route guards	②	P0	READY	anonymous/buyer/seller/admin navigation tests
RC-105	EP-04 Settings persistence	③ + ④	P0	READY	save → reload → re-login read-after-write
RC-106	EP-04 Product persistence	③ + ④	P0/P1	READY	CRUD/status/delete/slug conflict tests
RC-107	EP-05 Public user journey	②	P1	READY	anonymous public store/legal/disabled paid CTA E2E
RC-108	EP-06 Operator console	② + ④	P1	READY	admin JWT console, no setDevUser
RC-109	EP-07 Commerce reliability	④-B	P1	READY	idempotency/refund/subscription/audit/outbox tests
RC-110	EP-08 D1/runtime/deploy safety	④-C	P1	READY	fresh/upgrade migration, backup/restore, Worker deploy checks
RC-111	EP-09 Staging E2E	⑤	P1	READY	deployed-artifact Playwright evidence
RC-112	EP-10 Product/legal/support	① + PM	P1	READY	product copy/link review and launch decision

Defect classification

P0 — release blockers

• Buyer can potentially list cross-tenant subscriptions through seller/admin fallback behavior.
• Refund, fulfillment retry, ledger verification, and other privileged handlers can resolve an unauthenticated or service/dev identity incorrectly.
• Public store/widget behavior can fail open when settings/widgets are missing or private.
• FE has no route-level auth/role guard and production can still send X-Dev-User when no bearer token exists.
• Admin console uses setDevUser('[email protected]'), so it is not a real platform-operator surface.
• Seller settings/profile save can show success without server persistence.
• Production Pages previously shipped localhost API base; fixed at baseline, but regression must be covered.
• Production paid purchase path must remain disabled and must not create paid state.

P1 — required for release candidate

• Guest/public checkout model is inconsistent with authenticated seller store state.
• Product create/update can lose contract fields; slug uniqueness is not guaranteed.
• Outbox consumer semantics are incomplete; events must not be marked externally delivered without a consumer.
• Audit chain concurrent writes may fork or conflict.
• Worker/D1 lacks route-level automated tests and runtime observability.
• Staging Playwright targets local dev server rather than deployed staging artifacts.
• verify-deployment.ps1 expectations are stale.
• Seller settings/product screens lack reliable loading/error persistence behavior.
• Official staging FE target is staging.devpay.chu.plus; current Pages alias is staging.nougat-devpay.pages.dev.

P2 — post-RC or scoped limitation

• Legal entity, support channel, account recovery/deletion, and email ownership verification remain launch-policy decisions.
• Real PG and real email provider are excluded until separately approved.
• PG adapter and PostgreSQL production path are not release scope.
• MCP server remains future scope.

Independent QA test plan

Status: QA_PLAN_APPROVED_FOR_EXECUTION by the Independent QA lane for this RC cycle. This is an internal execution approval, not human/vendor sign-off.

Required checks before release recommendation

1. Build and static checks

   • cd fe && pnpm exec vue-tsc --noEmit -p tsconfig.json
   • cd fe && pnpm build:staging
   • cd fe && pnpm build:production
   • cd be && cargo test
   • cd be-cloudflare && worker-build --release
   • Worker route-level tests when added

2. Authorization matrix on Worker/D1

   • anonymous, buyer, seller A, seller B, admin, service/dev headers
   • protected GET/POST/PATCH/DELETE negative tests
   • cross-tenant read/write attempts
   • production X-Dev-User rejection

3. Persistence matrix

   • seller settings save → reload → re-login
   • product create/update/status/delete → reload
   • plan/license/entitlement field round-trip
   • duplicate slug/idempotency conflicts

4. Public browser E2E on staging

   • landing → legal pages
   • anonymous public store/product
   • private store/widget direct URL blocked
   • free feedback path where supported
   • production paid CTA remains disabled/non-paid

5. Role navigation E2E on staging

   • anonymous → login
   • seller → dashboard/onboarding
   • admin → /admin
   • buyer → no seller/admin access
   • expired/invalid token → login

6. Deployment verification

   • staging FE/API canonical URLs
   • production FE/API health only when explicitly authorized
   • deployed SHA and Pages deployment ID recorded
   • verify-deployment.ps1 updated and executed against staging

7. Data safety

   • fresh D1 migration
   • existing D1 upgrade
   • backup → scratch restore → row/hash verification
   • no destructive production test

Evidence recording rule

Every task handoff must report Task ID, Attempt ID, base SHA, result SHA, changed files, commands, PASS/FAIL/BLOCKED, environment, and unresolved defects. AI-generated product/design/QA outputs do not replace human vendor acceptance when contractual sign-off is required.