91 lines
6.4 KiB
Markdown
91 lines
6.4 KiB
Markdown
# Evidence Topic: Booking manual-review schema audit
|
|
|
|
## Metadata
|
|
|
|
- Date: 2026-07-31
|
|
- Status: Superseded implementation snapshot; audit-grade history gap remains active
|
|
- Scope: Live `booking_test`, Booking parser 2.0, migrations 008/014/015 and Web review composition
|
|
- Confidence: Fact
|
|
- Source: repeatable-read live metadata, DDL/contract/source inspection, focused tests, process timestamps and HTTP probes
|
|
- Last verified: 2026-07-31 11:21 +08:00
|
|
- Stale trigger: port-8766 restart, HTTP method-adapter change, first real draft/activation, or review-policy decision
|
|
|
|
## Question
|
|
|
|
Can the current Booking database model and running program support parser 2.0's unrecognized-room items and a human
|
|
confirmation loop?
|
|
|
|
## Evidence
|
|
|
|
- Migration 008 already supplied a coarse row gate: `parse_versions.parse_status` permits `needs_review`, while
|
|
`current_row_parses` and downstream views permit only accepted parses in accepted batches. The existing 867 parses are
|
|
all accepted; all 867 canonical room items have non-null room codes.
|
|
- At 11:12 +08:00 the live database still lacked migrations 014/015. At 11:19 +08:00 a new read-only snapshot found
|
|
`booking.current_source_batch`, `booking.extraction_drafts` and `booking.extraction_draft_items`. This audit did not
|
|
perform those concurrent migrations.
|
|
- The live singleton now points to accepted source batch 1. Both draft tables are empty, so no real upload/review/activate
|
|
transaction has yet been evidenced by their data.
|
|
- The live draft schema supports a basic latest-state operator loop: draft `reviewing/activated/superseded`; item
|
|
`confirmed/pending/deleted`; source sheet/row/item, Group Code, raw hotel/room text, canonical room type, quantity,
|
|
automatic flag, source fragment and timestamps. A pending item must have a null canonical room type; a confirmed item
|
|
must have one. All new constraints are validated.
|
|
- The schema is not an approval ledger. It has no assignee/reviewer/actor, reason/note, explicit decision timestamp,
|
|
before/after values, immutable item revision or append-only review event. No trigger makes closed drafts immutable or
|
|
enforces zero pending items at activation; these rules currently depend on application transactions.
|
|
- The new PostgreSQL repository uses serializable transactions plus a shared advisory lock, edits only reviewing drafts,
|
|
rejects pending/empty activation, writes confirmed items to accepted canonical facts, switches the current source and
|
|
closes the draft atomically. Re-extracting the same non-activated artifact deletes its earlier draft/items, so prior
|
|
manual edits are not durable history.
|
|
- The browser and business router model upload, list, edit, delete, discard and activate. However the browser sends
|
|
`PATCH` for confirmation and `DELETE` for item/draft removal, while `arr_web/server.py` implements only `do_GET` and
|
|
`do_POST`. Read-only loopback probes returned HTTP 501 for both `PATCH` and `DELETE`. The application-route unit tests
|
|
call the router directly and therefore do not catch this transport gap.
|
|
- The active port-8766 process started at 2026-07-30 23:19. The new Python composition files were modified at
|
|
2026-07-31 11:07-11:13, and the server has no hot-reload mechanism, so the running process has not loaded the new
|
|
repository/routes even though the database structure is now present.
|
|
- Twenty-seven focused parser/migration/review-contract/fake-repository/Web-route tests pass and a fresh source import
|
|
succeeds. No test executes draft CRUD/activation against a real PostgreSQL transaction, and no server-adapter test
|
|
covers `PATCH`/`DELETE`.
|
|
|
|
## Follow-up Resolution
|
|
|
|
Later on 2026-07-31, `arr_web/server.py` gained bounded PATCH/DELETE dispatch and real loopback socket coverage. The
|
|
supplied workbook then passed parser replay, the live review schema passed a read-only repository probe and the complete
|
|
source implementation was recorded in
|
|
[Booking Excel extraction program](2026-07-31-booking-extraction-program.md). The original audit remains evidence of the
|
|
before-state and of the still-open actor/reason/revision-history decision; its claim that PATCH/DELETE are currently
|
|
unimplemented is no longer authoritative.
|
|
|
|
## Original Point-In-Time Finding
|
|
|
|
The problem is not relational normalization itself. Canonical `booking.room_items` should remain accepted facts; pending
|
|
extraction belongs in a separate draft/workflow layer. The now-live 015 tables implement that separation and are enough
|
|
to represent a simple single-operator correction state.
|
|
|
|
At the 11:21 snapshot, the complete workflow was not runnable: the active service predated the new composition and the
|
|
HTTP adapter could not transport manual-confirm/delete calls. The later extraction-program work repaired and loaded
|
|
those implementation gaps. The audit-depth finding remains: if “人工确认” must be attributable and auditable, the schema
|
|
stores only the latest edited state, not who decided what, why, and how it changed.
|
|
|
|
## Original Point-In-Time Capability Classification
|
|
|
|
| Capability | Live database | Current program/runtime |
|
|
|---|---|---|
|
|
| Keep pending extraction out of canonical reports | Yes, through separate draft tables and accepted current-source gate | Repository models it; real PostgreSQL flow untested |
|
|
| Item pending/confirmed/deleted | Yes | UI/router/repository model it |
|
|
| Edit room type and quantity | Schema supports latest state | At 11:21, blocked because `PATCH` returned 501; later resolved |
|
|
| Delete item / discard draft | Schema supports status changes | At 11:21, blocked because `DELETE` returned 501; later resolved |
|
|
| Zero-pending atomic activation | Not declaratively enforced | Repository enforces it; real DB transaction untested |
|
|
| Reviewer/reason/history | No | No |
|
|
| Currently loaded on port 8766 | N/A | No; process predates new Python source |
|
|
|
|
## Original Open Items And Resolution
|
|
|
|
- PATCH/DELETE handling, server-level tests, controlled restart and Booking-source readiness are resolved in the later
|
|
extraction-program evidence.
|
|
- Add real-PostgreSQL draft CRUD, atomic activation and rollback tests before the first business workbook import.
|
|
- If audit-grade review is required, add actor/reviewer, action/reason, event time, old/new values or immutable item
|
|
revisions, optimistic concurrency and database transition guards.
|
|
- Run one controlled raw workbook through upload -> pending review -> confirmation/deletion -> activation -> company
|
|
report. No such business mutation was performed by this audit.
|