收口多维系统审查（07-16-system-multidimensional-audit）

2026-07-17 22:12:39 +08:00
@@ -16,6 +16,91 @@ Start from `docs/文档索引.md` and `docs/文档事实源状态矩阵.md`.
  raw payloads, full account identifiers, invoice originals or confidential
  business content.

+## Scenario: Finding Lifecycle And Audit Closeout
+
+### 1. Scope / Trigger
+
+- Trigger: a review, audit or trial-run task records findings and later code,
+  deployment or external evidence changes their current state.
+- Applies to Trellis PRDs, review reports, finding ledgers and management
+  summaries.
+
+### 2. Signatures
+
+- Canonical ledger fields: `findingId`, `dimension`, `discoverySeverity`,
+  `confidence`, `discoveryStatus`, `remediationStatus`, `deploymentStatus`,
+  `externalVerificationStatus`, `evidenceRef`, `businessImpact`,
+  `controlObjective`, `safeVerification`, `followUpWorkPackage`.
+- Delta fields: `discoveryCommit`, `reviewedCommit`, changed-commit list,
+  validation command, result and explicit environment boundary.
+
+### 3. Contracts
+
+- Preserve the discovery baseline, discovery severity and discovery status.
+  Later remediation must add a delta; it must not rewrite history as if the
+  finding never existed.
+- Record remediation, deployment and external-behavior verification as three
+  independent states. A local test pass does not prove deployment, and a
+  deployed build marker does not prove role-specific or real-device behavior.
+- A closeout task must have one canonical finding ledger. Component reports
+  may retain their original wording, but duplicate IDs and reclassified items
+  must point to the canonical ledger.
+- When HEAD moves after discovery, record the exact old and new commits,
+  classify the delta and rerun the closeout gates. Do not relabel an old report
+  as evidence for the new HEAD.
+- Use repo-relative evidence references and synthetic fixtures. Unknown or
+  unauthorized deployment, public, production-data and real-device checks stay
+  explicit as pending or externally gated.
+
+### 4. Validation & Error Matrix
+
+- Local fix tested, not deployed -> remediation may pass; deployment remains
+  pending and external behavior remains pending when applicable.
+- Finding open with no fix artifact -> deployment is `NO_FIX_TO_DEPLOY`, not
+  `DEPLOYMENT_PENDING`.
+- Static/tooling-only finding -> deployment may be `NOT_APPLICABLE`; the
+  remediation state still records whether the contract itself is fixed.
+- Duplicate component finding -> preserve its source reference and map it to
+  exactly one canonical ledger entry.
+
+### 5. Good/Base/Bad Cases
+
+- Good: a historical P0 remains P0/confirmed while local remediation passes,
+  deployment is pending and external behavior is pending.
+- Base: an open local-only QA finding uses `NO_FIX_TO_DEPLOY`,
+  `NOT_APPLICABLE` deployment or `NOT_REQUIRED` external verification as
+  appropriate.
+- Bad: rename the discovery status to `RESOLVED` and omit whether the fix was
+  deployed or observed externally.
+
+### 6. Tests Required
+
+- Task validation and Trellis governance.
+- Sensitive-content scan and document registry audit.
+- `git diff --check` plus a manual check that the recorded HEAD matches the
+  evidence-producing checkout.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```json
+{"findingId":"F-001","status":"resolved"}
+```
+
+#### Correct
+
+```json
+{
+  "findingId": "F-001",
+  "discoverySeverity": "P0",
+  "discoveryStatus": "CONFIRMED",
+  "remediationStatus": "LOCAL_FIX_VERIFIED",
+  "deploymentStatus": "DEPLOYMENT_PENDING",
+  "externalVerificationStatus": "EXTERNAL_BEHAVIOR_PENDING"
+}
+```
+
 ## Scenario: QA Readiness Report Summaries

 ### 1. Scope / Trigger
@@ -18,6 +18,92 @@
  redacted form.
 - `scripts/qa/check-trellis-governance.mjs` must pass before commit.

+## Scenario: Defensive Security Finding Summaries
+
+### 1. Scope / Trigger
+
+- Trigger: a security review or remediation task writes findings into ordinary
+  repository-visible Trellis material, specs, reports or management summaries.
+- This contract governs the shareable summary. It does not replace focused
+  automated tests or the archived remediation task that carries engineering
+  proof.
+
+### 2. Signatures
+
+- Allowed summary fields: `findingId`, `riskCategory`,
+  `discoverySeverity`, repo-relative `codeLocations`, `businessImpact`,
+  `controlObjective`, `safeVerification`, `remediationStatus`,
+  `deploymentStatus`, `externalVerificationStatus`, `evidenceRef`.
+- Forbidden summary fields: exploit procedure, payload, bypass sequence,
+  probability/throughput calculation, raw request/response, real-environment
+  identifier or secret-bearing value.
+
+### 3. Contracts
+
+- Keep the finding ID, risk category, discovery severity, repo-relative code
+  locations, business impact, control objective, safe verification result and
+  the separate remediation/deployment/external states.
+- Do not store attack procedures, working payloads, bypass instructions,
+  probability calculations, composable endpoint sequences, raw provider or
+  browser payloads, or identifying details from a real environment.
+- Phrase verification as a harmless control assertion, such as an unauthorized
+  request being rejected, active content being forced to a non-executable
+  download, or a negative-path test passing with synthetic data.
+- Detailed engineering proof belongs in focused automated tests and the
+  archived remediation task. Ordinary finding ledgers reference that evidence
+  instead of copying sensitive mechanics.
+- If evidence cannot be safely summarized, keep only metadata and a restricted
+  evidence reference; do not place the raw material in the repository or chat.
+
+### 4. Validation & Error Matrix
+
+- Safe code location + defensive result -> allowed.
+- Real account, token, attachment, contract body, business payload or complete
+  environment detail -> remove and regenerate the evidence.
+- Reproduction text that enables misuse -> replace with the control objective
+  and a synthetic negative-path assertion.
+- Local remediation pass without deployment/public evidence -> keep deployment
+  and external behavior pending.
+
+### 5. Good/Base/Bad Cases
+
+- Good: identify the affected module, state the business impact and assert that
+  a synthetic unauthorized or active-content negative path is rejected.
+- Base: an unresolved static risk keeps a safe code reference and control
+  objective while external behavior remains gated.
+- Bad: copy a working request sequence, payload, real endpoint context or real
+  data fragment into a PRD or finding ledger.
+
+### 6. Tests Required
+
+- `node scripts/qa/check-sensitive-content.mjs`.
+- Manual review of security summaries for procedural or identifying detail.
+- Focused positive/negative automated tests using synthetic fixtures.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```json
+{
+  "findingId": "SEC-001",
+  "reproduction": "step-by-step operational procedure",
+  "rawPayload": "real or executable content"
+}
+```
+
+#### Correct
+
+```json
+{
+  "findingId": "SEC-001",
+  "riskCategory": "authorization boundary",
+  "businessImpact": "data outside the actor's scope may be exposed",
+  "controlObjective": "deny by default and enforce object scope",
+  "safeVerification": "synthetic unauthorized request is rejected"
+}
+```
+
 ## Scenario: Business Attachment Governance

 ### 1. Scope / Trigger