OAKISS1 完成全业务 KISS 审查台账

2026-05-25 21:22:54 +08:00
@@ -31,7 +31,8 @@ Read only what is relevant:
 - OALAUNCH1 is the current final-enable gate after OAOPS1/ASSET1D/OSMOKE1: do not treat ASSET1D completion or `PASS_OA_REAL_USE_DAILY_READY` as final launch approval. Use `scripts/qa/run-oa-final-launch-readiness.sh` to aggregate evidence only; it must not create business data, execute payments, write WeCom, reset/restore the production DB, print secrets, or mark final launch ready without real business closeout, 7-day stabilization, permission matrix acceptance, backup/restore drill evidence, data-governance/training acceptance, and Day 7 Go/No-Go. Valid conclusions are `PASS_OA_LAUNCH_READY`, `PASS_WITH_FINDINGS`, `PAUSED_MANUAL_CONFIRMATION`, and `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`. Permission or backup/restore fixes require read-only reviewer review before launch acceptance.
 - OPOLICY1 is the current policy-system alignment lane after OMAT1/OALAUNCH1 review: external company policies under `/home/shunli/Projects/faculty-daily-assistant/公司/制度体系建设_20260524` are adjusted to a small-team V1口径 first, then hyb-oa facts are aligned. Treat policy parameters, data-retention boundaries, seal-use ledger, approval-exception SOP, policy signoff, and P2 freeze rules as OALAUNCH1 data-governance gates. Do not assume budget hard control, complex procurement/tendering, e-signature, full e-archive, ERP/bank deep integration, or AI rule writes are pre-launch requirements. For V1, contract registry summary/archive/offline archive fields and existing attachment audit can carry seal-use traceability; announcements/manual evidence can carry policy notices/signoff until a later Issue proves dedicated schema is required. Never copy sensitive policy text, thresholds, confidential contract bodies, credentials, or full local paths into repo docs.
 - OAFLOW1 is the current OA reimbursement approval hardening lane: `wangshunli/HYD000006` as `ceo + admin` must not be assigned a fake direct manager, must not self-approve, and `admin` must not be treated as business approval authority. Reimbursement `approval_rules` now support `ownerSelfFallbackRole`; OAFLOW1 V1 only allows `finance_mgr` or null, and existing enabled rules default to `finance_mgr`. For CEO owner self-applications with no direct manager, build and persist a new workflow snapshot by replacing the first `manager` node with `finance_mgr`, removing the owner's own `ceo` node and duplicate fallback role. Precheck, submit, and approval advancement must use the same snapshot; public deployment and low-risk owner reimbursement verification require separate approval and must not execute real payment.
- OAFRONT6 is the current frontend maturity small-step lane after OAFRONT5: use `issues/2026-05-25_12-29-03-oa-frontend-maturity-small-step-v1.csv` for scoped design follow-ups only. Route-title cleanup, asset registry sectioning, mobile visual-matrix stability, and contract registry form grouping are implemented and deployed; long-number display compaction is implemented locally and still needs deployment plus public PC readonly visual rerun before closure; Portal observation remains later feedback-driven work. Do not treat OAFRONT6 as approval for a broad redesign, business logic changes, public writes, deployment, or final launch readiness; further implementation still needs `docs/产品设计规则.md`, focused Playwright/visual evidence, and OALAUNCH1 gates.
+- OAFRONT6 is the current frontend maturity small-step lane after OAFRONT5: use `issues/2026-05-25_12-29-03-oa-frontend-maturity-small-step-v1.csv` for scoped design follow-ups only. Route-title cleanup, asset registry sectioning, mobile visual-matrix stability, contract registry form grouping, and long-number display compaction are implemented, deployed, and publicly rerun; report `artifacts/qa-flow/oafront3-pc-readonly-visual-20260525-202712/summary.json` is `PASS_PC_READONLY_VISUAL_READY` with `findingCount=0`. Portal observation remains later feedback-driven work. Do not treat OAFRONT6 as approval for a broad redesign, business logic changes, public writes, deployment, or final launch readiness; further implementation still needs `docs/产品设计规则.md`, focused Playwright/visual evidence, and OALAUNCH1 gates.
+- OAKISS1 is the current all-business-flow KISS review lane after OAFRONT6/OALAUNCH1: use `issues/2026-05-25_20-53-34-oa-business-flow-kiss-review-v1.csv` to record review evidence and suggestions across reimbursement/OCR, approval, procurement/expense, contracts/projects, payment/AP, invoice pool, assets, permissions, mobile/WeCom entry, and operations. It follows MAGI wording as an audit structure only: review first, run read-only evidence and record gaps second, then produce KISS keep/simplify/defer/manual-SOP recommendations. It must not create business data, execute payments, delete data, write WeCom, change production config, or replace OALAUNCH1 gates. Current evidence includes OAOPS1 daily `artifacts/qa-flow/oa-real-use-daily-20260525-205848/summary.json`, OALAUNCH1 `artifacts/qa-flow/oa-final-launch-readiness-20260525-211233/summary.json`, permission matrix `artifacts/qa-flow/oa-permission-matrix-20260525T130601Z/summary.json`, PC visual `artifacts/qa-flow/oafront3-pc-readonly-visual-20260525-210819/summary.json`, remote owner route `owner-application-approval-route-20260525-oakiss1`, and ASSET1D evidence. Treat the top remaining launch gates as real business closeout, 7-day stabilization, backup/restore drill, and data-governance/training acceptance.
 - OMAT1 is the current maturity-gap review goal after OALAUNCH1: use `issues/2026-05-23_17-20-00-oa-maturity-gap-review-v1.csv` as the reviewable ledger for every problem or suggestion. It includes domestic benchmark sources, a domain capability comparison matrix, manual decision Q&A checklist, review decision packet, status audit, and MAGI round reviews in the manual trial-run report, the small-team rule that maturity means controlled operation before feature breadth, explicit adopt/defer/reject decision回填, and a need for a concise evidence view. Follow the MAGI cycle wording as audit structure only: review/evaluate first, record or solve bounded evidence gaps second, then prioritize direction. Do not implement OMAT1 suggestions until the user chooses adopt/defer/reject and a proper Issue CSV exists for the adopted work.
 - WEGOV1 changes the current WeCom route to "Enterprise WeChat owns mature HR/attendance flows; OA stores self-owned history, audit, entry, messages, and emergency fallback." Treat four domains explicitly: WeCom-owned domain is check-in, leave, missed punch, outing, overtime, leave balance, and HR assistant; OA-owned domain remains reimbursement, procurement, contracts, projects, payments, invoices, bank receipts, sensitive attachments, and operating audit; OA archive domain stores WeCom business history, full external keys, and necessary snapshots; OA emergency domain is manually enabled only when WeCom is unavailable. Do not assume a full isolated WeCom sandbox; use the controlled test domain `SMOKE002 -> SMOKE101`, `OA-POC` templates, low-risk approvals, synthetic tests, public live runners, and limited real-device confirmation. WARCH1 now supplies the minimum leave/missed-punch archive implementation, WARCH2 supplies the formal read-only history query surface, and WROAD2 supplies controlled ops daily checks. Do not start deep mirror until WROAD2-CLOSEOUT, WROAD2-BIZ1, WAPPR1, WRULE1, WAUTO1/WEXT1LD, WFULLSMOKE1, WTCLOSE2, WEXT1-FORMAL, WREAL1 question gates or explicit approval, and the mirror stage's own contract are complete.
 - For reimbursement, invoice, OCR, duplicate invoice, or attachment work, read `docs/报销发票附件规则.md` and `references/reimbursement.md`.