治理(08-11-internal-oa-finance-backoffice-positioning-and-navigation-reduction): 固化财务后台定位与写入定性

2026-08-13 21:27:53 +08:00
@@ -2014,6 +2014,72 @@ node scripts/qa/payment-batch-flag-snapshot.mjs restore --snapshot-file "$REPORT
 <Link to="/mobile/payment-batches">进入付款</Link>
 ```

+## Scenario: Production Configuration Write Observation And Uncertainty
+
+### 1. Scope / Trigger
+
+- Trigger: an approved production runner changes feature flags or another versioned configuration through an API, then uses browser/network observation, response parsing or local counters to decide whether the write landed or whether rollback is needed.
+- Purpose: prevent an observer defect from turning a known successful write into an unnecessary compensating write, while preserving zero retry and exact audit evidence.
+
+### 2. Signatures
+
+- Forward write: the approved mutation endpoint, for example `POST /api/system/feature-flags/batch`, with frozen `expectedVersion` values.
+- Authoritative readback: GET the changed resources and compare `version`, configured value and effective state with both the PRE snapshot and the expected POST snapshot.
+- Independent evidence: action-specific audit total and per-target changelog deltas.
+- Observer sources must be named separately: page requests, browser-context requests, `APIRequestContext`, server response and audit/readback.
+
+### 3. Contracts
+
+- A local request counter is evidence only for the transport it actually observes. A Playwright `page.on("request")` listener does not observe writes sent through `context.request.fetch` or another `APIRequestContext`.
+- Missing observer events, contradictory counters, missing output, non-zero transport status or invalid JSON enters `APPLY_UNCERTAIN`. The first action is read-only resource readback; audit and changelog are the second independent source.
+- Before readback classifies the result, prohibit every further mutation: no forward retry, rollback, compensation, single-item repair or workspace/config cleanup. Rollback is a state change and follows the same uncertainty rule as retry.
+- Readback equals expected POST (`version=PRE+1`, desired value/effective state on every target) -> classify the write as applied and continue POST verification. A zero local counter cannot override authoritative state.
+- Readback equals the PRE snapshot -> classify as not applied and stop. A later attempt requires a fresh approval/version lock unless the original approval explicitly defines another attempt.
+- Partial or mixed readback -> return `STOP_FOR_MANUAL_DECISION`, record a contract/product finding and stop. Do not continue POST, auto-rollback or conceal a broken atomicity contract with manual repair.
+- Execute an approved rollback only after the forward result is known and a defined POST acceptance condition actually fails. Capture rollback response, final readback and audit deltas separately from the forward evidence.
+
+### 4. Validation & Error Matrix
+
+- Response `count` is correct but local observed-write count is zero -> `APPLY_UNCERTAIN`; GET versions/state, do not rollback from the counter alone.
+- Response missing or JSON invalid -> `APPLY_UNCERTAIN`; GET versions/state and audit, never retry blindly.
+- All targets at expected POST -> continue read-only POST checks; rollback only for a real approved acceptance failure.
+- All targets at PRE -> stop with zero compensating writes.
+- Some targets changed -> `STOP_FOR_MANUAL_DECISION`; stop, preserve evidence and request an explicit human decision. Neither continue nor rollback is automatically correct.
+- Readback itself fails -> state remains unknown; stop with zero further mutation.
+
+### 5. Good/Base/Bad Cases
+
+- Good: `APIRequestContext` writes a three-item batch while a page listener reports zero; GET shows all three at `PRE+1`, audit is `+3`, so the runner continues POST verification without rollback.
+- Base: the batch response and observer agree, readback confirms the expected state, and the audit delta matches target count.
+- Bad: treat a page-only counter as authoritative for a context request and immediately restore the PRE values before checking current versions.
+- Bad: call rollback because it is pre-authorized while the forward result is still unknown.
+
+### 6. Tests Required
+
+- Local integration/harness case where the write is sent through `APIRequestContext`, the page listener observes zero, the server returns success and readback shows `PRE+1`; assert no rollback and no retry occur.
+- Cases for response success/counter agreement, response missing with POST state, response missing with PRE state, readback failure and partial/mixed state.
+- Assert mutation ordering: forward at most once -> uncertain readback/audit only -> either POST verification or stop -> rollback at most once only after a concrete approved acceptance failure.
+- Assert final evidence reconciles response count, readback versions, global audit delta and per-target changelog delta; no one source may silently override contradictions.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```text
+forward response count=3 + page observer count=0
+-> assume failure -> rollback immediately
+```
+
+#### Correct
+
+```text
+forward response/counter disagree -> APPLY_UNCERTAIN
+-> GET every target version and state -> reconcile audit/changelog
+-> expected POST means continue verification
+-> PRE means stop
+-> rollback only after a real approved POST failure
+```
+
 ## Scenario: Unique Production Administrator Break-Glass Reset

 ### 1. Scope / Trigger
@@ -76,37 +76,44 @@ otherwise -> defer, hide, freeze or keep as a manual SOP
 **Related**: the evidence-backed baseline and initial retirement candidates are
 recorded in task `07-26-small-team-internal-oa-review`.

-### Design Decision: Adoption Mode Before Product Expansion
+### Design Decision: Finance-Backoffice Scope And Focused Adoption

 **Context**: the 2026-08-11 production read-only census found extremely low
 team adoption across the system. This does not prove that missing features are
 the cause; several workflows intentionally live in Enterprise WeChat or manual
 processes.

-**Decision**: management must choose one operating mode before any new product
-feature task starts:
+**Decision**: separate product scope from adoption intensity. hyb-oa is the
+company's finance and low-frequency ledger backoffice, not its general daily
+collaboration suite. Reimbursement, invoices/OCR, approval, payment and AP are
+OA-primary workflows and should be used for real work. Contract, procurement
+and asset ledgers remain available but frozen until real events occur. HR,
+attendance and daily collaboration stay Enterprise-WeChat-primary. Project is
+currently a frozen zero-use domain and must not be disabled when that would
+degrade an OA-primary finance flow.

-1. **Enforced use**: designate a real near-term workflow, require the team to
-   complete it in OA, and use observed blockers—not guessed needs—as product
-   input.
-2. **Ledger fallback**: keep OA as a low-frequency record, control and recovery
-   system; reduce navigation and maintenance surface instead of expanding it.
+Payroll, performance, ERP/integration, budget and cutover capabilities are
+retirement-review candidates, not approved removals. Authentication, least
+privilege, payment maker-checker, audit, backup/restore and leaver revocation
+remain mandatory regardless of frequency.

-Until the mode is recorded in the business fact source, freeze new product
-features. Real production defects and the security/recovery baseline remain
-eligible. Reversible navigation reduction is valid under either mode, but it
-still requires its own Trellis task and approval for production configuration
-writes. Do not create that follow-up task as a side effect of a census or review
-task.
+Do not implement technical coercion to manufacture adoption. Requiring the
+next reimbursement to use OA is a management rule; notification expansion,
+onboarding guides, channel blocking or reminder machinery need observed user
+friction before they can become product work. The old R63-R66 expansion
+schedule is superseded.

 ```text
-adoption mode undecided -> no new product feature task
-mode A + observed team blocker -> consider one small product task
-mode B -> prefer hide, freeze, retire review, manual SOP or necessary upkeep
+OA-primary finance flow + observed blocker -> consider one small product task
+low-frequency ledger + no real event -> keep available and frozen
+Enterprise-WeChat-primary or cheaper reliable substitute -> do not duplicate
+outside the focused scope -> hide, freeze or start a separate retirement review
 ```

 **Related**: task `08-11-internal-oa-usage-census-and-simplification` contains
-the evidence boundary and module decision matrix.
+the evidence boundary and module decision matrix. Task
+`08-11-internal-oa-finance-backoffice-positioning-and-navigation-reduction`
+records the adopted scope and first reversible navigation reduction.

 ## Stop Conditions