This evidence snapshot records the application-dev target database, DDL apply
and replay status, targeted verification commands, fresh-jar smoke outcomes,
and cleanup proof for the writtenoff formal-table batch.
Constraint: Evidence must remain aligned with the backend writtenoff formal-table batch and the actual application-dev database
Rejected: Fold evidence into unrelated doc updates already present in this branch | would mix scopes and obscure traceability
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Update this evidence if later writtenoff smoke is rerun on a different port or with different seeded IDs
Tested: Reviewed against backend compile/test results and direct psql cleanup verification on 2026-04-17
Not-tested: No additional doc rendering/export pipeline run for this evidence-only change
This adds the rollout evidence for REV004 bad-debt formal-table work,
covering DDL application, targeted verification, fresh-jar HTTP smoke,
and cleanup proof on the application-dev database.
Constraint: Evidence scope stays limited to bad-debt formal-table rollout and should not absorb unrelated REV004 docs backlog
Rejected: Wait to document until writtenoff/price-diff formalization lands | delays a completed bad-debt evidence slice
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If later bad-debt semantics expand beyond payState write-back, append a new evidence note instead of rewriting this rollout record
Tested: Evidence content cross-checked against compile/test/DDL/HTTP smoke outputs captured in this session
Not-tested: No doc export/render verification performed
This documents the prestorage formal-table rollout status, including test DB
DDL application, HTTP smoke evidence, cleanup proof, and the updated
formal-table status matrix for REV004.
Constraint: Documentation must stay scoped to prestorage formal-table evidence and status updates only
Rejected: Fold unrelated REV004 evidence backlog into this commit | would dilute the deliverable and review scope
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When process/attachments become strict formal-first, update the status matrix and evidence instead of replacing this rollout record
Tested: Evidence file cross-checked against backend compile/test/DB/HTTP smoke outputs
Not-tested: No independent docs rendering/export verification performed
This documents that the formal-table deploy SQL has been applied to the
application-dev database, that the previous real-db blocker is resolved,
and that the date-mode late-fee reduce canary now passes against the
test database.
Constraint: Evidence must match the verified dev database and latest canary output
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep evidence updates aligned with the exact environment and command outputs used for verification
Tested: Evidence cross-checked against psql deployment output and fresh canary pass
Not-tested: No additional business flow beyond the documented late-fee date-mode canary
Document the minimal dictionary additions and field-binding rules needed to
let REV004 front-end queries and dropdowns use system-managed object and
status semantics while continuing to reuse the existing legacy reason/type
dictionaries.
Constraint: Existing dictionary taxonomy must remain stable for historical pages
Constraint: REV004 needs explicit object/status dictionaries plus a redink reason set for FE binding
Rejected: Rename legacy dictionaries into a new unified taxonomy | too broad for this delivery and risks breaking existing pages
Rejected: Keep object/status values as code-only enums | insufficient for frontend dictionary binding
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: `payment_reason` is only a transitional binding for `WRITTENOFF_ADJUST`; introduce a dedicated writtenoff reason dictionary only when that object stabilizes long-term
Tested: Applied `sql/rev004_account_adjust_dict_seed.sql` to sw_system test DB and verified inserted dict types/data
Not-tested: Frontend page consumption against the new dictionary bindings
Add the Nuoshuitong documentation outputs to the project progress ledger so the documentation lane has a traceable handoff point for review and follow-on implementation work.
Constraint: Keep this update limited to governance tracking for the newly added Nuoshuitong design pack
Confidence: high
Scope-risk: narrow
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Add a Nuoshuitong documentation set covering the implementation checklist, split interface spec notes, normalized enums, and database/DDL guidance so follow-on integration can start from a consistent source of truth.
Constraint: Current phase is documentation-first and must not require backend/frontend code changes
Rejected: Merge the material directly into formal master design docs now | would broaden scope before the integration model and dialect strategy are reviewed
Directive: Treat these guides as integration-layer inputs until they are reconciled with formal technical design masters
Confidence: high
Scope-risk: moderate
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Document the existing REV-002 backend billing-generation path and preserve a conservative partial-implementation judgment so the design stays aligned with current code evidence.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
