# Drawing register: operation and recovery

## Supported deployment

Run one Node 24 process on the local operator computer with a private data directory. Files and SQLite metadata stay on the same local filesystem. Bindings and Host/Origin checks restrict access to localhost. The author, reviewer and reader identities are public fixtures that demonstrate separate permissions.

```sh
node app.ts --seed --data data --port 8012
node run-tests.mjs
node complete.mjs
```

The server can run under an OS service account whose permissions are restricted to the source, data and backup locations. Use an absolute `--data` path in a service definition. SIGTERM closes the database after HTTP requests finish. On restart, persistent drawings and files remain; in-memory sessions expire, requiring another login.

## Export and restore

As reviewer, prepare a register export. It contains only the reviewer's accessible groups. A digest covers the exact JSON payload, and each PDF has its own digest. The client now reports that the export is prepared, without claiming that the browser has finished saving the file.

```sh
node app.ts restore drawing-register-export.json --data restored-register
node app.ts --data restored-register --port 8012
```

The destination must not exist and its parent must exist. Keep the original service stopped while inspecting a restored copy on the same port. Restore validates the manifest, object bytes, revision pointers and matching approvals. An ordinary restore error removes only its own newly created destination. A `RESTORE_INCOMPLETE` marker prevents a process from serving a partial restore left by an abrupt termination. Preserve that directory for diagnosis and restore the original export into another new directory.

After restore, sign in, confirm the current release version, download its PDF and compare the hash, inspect prior reviews and run reconciliation. Missing and mismatched files are separate from pending and orphaned files. Reconciliation never deletes objects. Do not release a revision while those checks disagree.

## Completed process and client rehearsals

`node complete.mjs` executes the actual client source with a small modeled DOM, native SHA-256 hashing and a real HTTP/SQLite backend. The sequence uploads a PDF, loses a connection after pending metadata, rejects wrong retry bytes, retries the original file, approves it as a separate reviewer, releases it, and captures the exact export Blob. Those bytes restore the released file and its review history. The modeled DOM and download sink are disclosed; no browser file-picker or operating-system save completion is inferred.

A separate child-process drill kills the real server after an uploaded file but before finalization, then after a committed release. It verifies pending-file recovery, session invalidation, revision history, PDF bytes, export/restore and rejection of a corrupt bundle. The primary regression suite also injects a restore database failure and verifies cleanup, and confirms that an incomplete-restore marker blocks startup.

## Remote deployment and capacity run-through

`deployment-inputs.json` holds the reference inputs and `node deployment-model.mjs` runs the decisions. The selected envelope is 12 two-MiB PDF revisions, 24 MiB of source bytes, within the 48 MiB aggregate export limit. A conservative in-memory estimate includes the raw buffers, two base64 JSON copies and 1 MiB of metadata; this is a planning bound, not a heap profiler measurement. Seven maximum-size ten-MiB PDFs exceed the export limit and are rejected. The limit is deliberate and visible.

The modeled recovery policy is a verified export every 15 minutes, five minutes to restore and three minutes to reconcile. It meets the declared 15-minute RPO/RTO inputs. A daily export and a 33-minute recovery fail those targets. The assumed series availability of a network, gateway and host is below 99.9%; this is a single-host design.

The hypothetical remote variant requires TLS, a real identity provider with separate author/reviewer permissions, persistent authorization, private object storage, object version retention, bounded streaming export and monitored backups. The model rejects public fixture identities and missing TLS. These are evaluated deployment decisions, not installed remote infrastructure. The delivered localhost app retains its own access guards.

## Fault decisions

| Fault | Response |
| --- | --- |
| Interrupted file upload | Keep the pending revision and retry the original file. Digest/size must match. |
| Stale approval | Review the latest verified revision. Approval cannot transfer between digests. |
| Competing release | Refresh the release version; only the expected current version can advance. |
| Missing or mismatched PDF | Block download/release; preserve storage and restore verified bytes/history. |
| Orphan PDF | Preserve it for an operator decision; do not delete during reconciliation. |
| Damaged export | Reject before replacing a live directory. |
| Process restart | Reauthenticate. Confirm pending objects before retrying finalization. |
| Incomplete restore marker | Refuse serving the partial store; restore into a new path. |

SIGKILL is process failure, not physical power loss. Files are fsynced, but the filesystem's directory metadata and actual storage device power-loss behavior are not physically qualified. The PDF header and digest checks do not establish engineering correctness, malware safety or a manufacturing approval.