# Saved tokenization drafts in administration

Apply only `migrations/202610010003_tokenization_draft_visibility.sql` to the
existing tokenization/customer-activity schema. It is independently deployable and
does **not** require or apply pending `202610010001_admin_login_security.sql`,
temporary KYC, or any unrelated migration. The new migration is transactional and
repeatable. It preserves existing customer-access wrappers and admin role checks.

Previously the administrator's tokenization queue explicitly excluded `draft`,
and the customer profile had no tokenization request list. An unfinished
application could therefore be saved in the database while absent from those
administrative views. This migration exposes saved drafts to authorized owners;
other customers still see only their own requests.

The existing `start` and `save` actions now accept optional `wizard_step` values
`0` (asset), `1` (information), `2` (documents), or `3` (review/send). Normal
ownership, optimistic versioning, field validation, and suspended/closed-account
guards still apply. Omitted stage leaves the saved value unchanged on save. New
requests default to step zero; older requests keep `null`, with a display stage
inferred from actual saved information/documents. Stage changes enter the retained
customer activity stream. The existing `updated_at` indicates the last save.

Every tokenization request view adds:

```ts
wizard_step: number | null;
progress: {
  filled_fields: number;
  total_fields: number;
  required_fields: number;
  completed_required_fields: number;
  uploaded_documents: number;
  required_documents: number;
  uploaded_required_documents: number;
  current_step: number;
};
```

Field counts use the selected asset schema and nonempty saved values. Document
counts require a completed upload and an existing private storage object. Missing,
deleted, rejected, or correction-requested documents cannot satisfy required
document completion. This progress describes completion, not ownership, validity,
approval, or issuance. For submitted requests the status determines step three;
an available tokenomics proposal determines step four. Client stage metadata cannot
override those lifecycle states.

The owner customer-profile response adds `tokenization_requests`, containing that
customer's saved request fields, documents, status, version, and progress. The
dashboard's latest-request feed includes drafts labeled with their actual status
and latest saved time; draft requests remain excluded from pending-review totals.
Draft visibility does not enable approve/reject/propose/issue actions before
submission and never creates a wallet balance. Reading these views does not mark
requests submitted, send notifications, or change audit/history records.

After deployment, run `tokenization-draft-visibility-smoke.sql` in the SQL editor
for read-only structure/aggregate checks, then open a saved unfinished application
in the owner administration panel and its customer profile. Only data saved to the
server is available to administration; browser-only unsaved edits require the
marketplace draft-save flow to complete first.

Local validation:

```sh
node --test tests/tokenization-draft-admin-db.test.mjs
```

Tests apply real prerequisite migrations while deliberately omitting temporary
identity approval and admin-login changes. They cover the former hidden-draft
behavior, read-only visibility, partial saves, private documents, progress,
submission requirements, concurrency, activity recording, and access isolation.

For rollback, preserve the new nullable column and retained activity records.
Restore only the affected function definitions from their pre-deployment snapshot,
including the existing access wrappers; do not rerun the old tokenization
migration wholesale or drop request/history records. This reverses visibility and
stage-saving support and should be coordinated with the marketplace/admin UI.

Deployment and verification:

- Applied only migration `202610010003` to project `wlsxzyeernwtsetzyltq`
  through the authenticated SQL editor; it returned success. The pending admin
  login-security migration was not applied.
- The pre-deployment read-only aggregate found one solar-plant draft with no
  populated specification fields. Unsaved browser-only values cannot be recovered
  from that record; the UI must display the stored state accurately.
- Database regression tests passed for draft visibility, progress, private
  documents, activity, version conflicts, ownership and submission guards.
- Admin view tests and both application builds passed. Final authenticated admin
  visual inspection requires a renewed administrator session; the current page
  displays the login form.