记录(08-08-production-authenticated-readiness): 收口生产登录态部分验收

.trellis/spec/hyb-oa/deployment-trialrun.md

@@ -1989,3 +1989,112 @@ capture audit baseline -> require baseline + 1
 atomic rename -> compare identifier/password in-process -> login once
 -> change password once -> final verify -> destroy temporary material
 ```
+
+## Scenario: Zero-Retry Production Authenticated Readiness
+
+### 1. Scope / Trigger
+
+- Trigger: a separately approved production-readiness task uses one real login
+  attempt to inspect an already deployed feature without business writes.
+- Purpose: preserve the only authentication attempt and produce a precise safe
+  result when production data does not contain the samples needed by the UI
+  assertions.
+
+### 2. Signatures
+
+- Browser execution contract: `workers=1`, `retries=0`, one login submission
+  per approved role.
+- Product status-label source:
+  `features/contractsRegistry/presentation.ts` (or the current shared mapping
+  imported by the production page under test).
+- Required evidence fields: `stage`, `loginAttempts`, `loginHttpStatus`,
+  `sampleCategory`, `sampleCount`, `businessMutationCount`, and the relevant
+  endpoint-specific request count such as `terminatePostCount`.
+
+### 3. Contracts
+
+- Define fine-grained safe stages before execution, including authentication,
+  route reachability, list loading, sample selection, detail loading and each
+  optional state-specific assertion. A single catch-all "browser failed" stage
+  is not acceptable evidence for a zero-retry run.
+- UI labels and state words must come from the current product source or shared
+  presentation mapping. Do not retype remembered Chinese labels in the runner;
+  a stale label can consume the only login while testing an assertion that is
+  not part of the deployed product contract.
+- Query or observe the available sample categories without creating data.
+  Report each missing category and count independently. Missing `active`,
+  `archived` or `terminated` data makes only its dependent assertions
+  `PAUSED`; it is not an authentication failure and does not authorize a retry.
+- Install network mutation counters before navigation. A stopped run may claim
+  safety only from explicit counts such as `terminatePostCount=0` and
+  `businessMutationCount=0`, not from the fact that a detail page was never
+  reached.
+- Record authentication side effects separately from prohibited business
+  writes. A successful login normally creates a session and login audit; do not
+  summarize that run as "production writes = 0". If logout is not reached,
+  record the residual session and follow the approved session-lifecycle policy
+  rather than revoking it directly without authority.
+- Recheck any state-based rollback window before and after the browser run.
+  Missing samples and a still-open window remain independent facts.
+
+### 4. Validation & Error Matrix
+
+- Login fails once -> stop with the authentication stage and re-read lock/failure
+  state; no second login.
+- Login succeeds but the required sample count is zero -> authentication PASS,
+  sample-dependent UI checks `PAUSED`, mutation counters must remain zero.
+- Runner label differs from the current shared product mapping -> runner
+  contract defect; stop without relabeling the product and do not rerun the
+  consumed login solely to repair evidence.
+- Mutation counter is missing or positive -> no safe read-only claim; classify
+  the exact endpoint/stage and stop.
+- Browser exits before logout after a successful login -> record the new session
+  as an authentication side effect; do not conceal it or revoke it by an
+  unapproved database write.
+- Rollback window closes while the runner sent no relevant mutation -> record a
+  concurrent real-user event and switch to the approved roll-forward policy.
+
+### 5. Good/Base/Bad Cases
+
+- Good: one login returns 200, the contract table is empty, the runner reports
+  `sampleCategory=contracts`, `sampleCount=0`, all mutation counters are zero,
+  and detail/termination assertions remain explicitly `PAUSED`.
+- Base: suitable existing samples are present, so the runner checks only the
+  approved read-only UI stages and exits with zero business mutations.
+- Bad: hard-code a remembered label, fail at list selection, then report only
+  "browser failed" and spend a second login to discover that production had no
+  sample.
+- Bad: say "no production writes" after a successful login created a session
+  and audit row.
+
+### 6. Tests Required
+
+- Before a live run, statically compare every runner-owned status label with the
+  current shared presentation mapping, or import that mapping directly.
+- Exercise a local zero-sample fixture and assert it emits the independent safe
+  category/count, preserves authentication PASS and marks only dependent UI
+  checks `PAUSED`.
+- Assert `workers=1`, `retries=0`, login submission count at most one per role,
+  and mutation listeners installed before the first application navigation.
+- Evidence review must reconcile login attempts with session/audit changes and
+  reconcile every unexecuted UI assertion with its sample count and stage.
+- Production execution still requires explicit approval, pre/post rollback
+  window snapshots, sensitive-content scanning and a read-only reviewer.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```text
+remembered UI label -> one broad browser stage -> sample lookup fails
+-> retry login -> report "no production writes"
+```
+
+#### Correct
+
+```text
+current shared mapping -> fine-grained stages + mutation listeners
+-> login once -> classify sample categories/counts
+-> zero sample means dependent checks PAUSED, not auth failure
+-> reconcile session/audit side effects -> post-window snapshot
+```