jb/shd.build
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: refine ISAC design and prepare production deployment
Validate and deploy production / validate (push) Successful in 18s
Details
Validate and deploy staging / validate (push) Successful in 18s
Details
Validate and deploy production / deploy (push) Successful in 1m1s
Details
Validate and deploy staging / deploy (push) Successful in 28s
Details

Browse Source
This commit is contained in:
JB
2026-07-26 12:25:47 -04:00
parent 75faef50b8
commit 2e868d86ff
153 changed files with 64660 additions and 264 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+11 -27
View File
@@ -90,35 +90,19 @@ This guard prevents accidental merging or overwriting of contributor data.
Stop the application before backup or restore so the embedded database file is
not locked by another process.
## Low-downtime development migrations
## Development database maintenance
The development database is a shared working data source: contributors may be
entering ISAC records while application development continues. Database changes
therefore use a prepared migration window rather than taking the server down at
the beginning of implementation.
The development database remains valuable persistent data, but it is no longer
served to outside contributors and does not require a low-downtime migration
window. Stop only this project's development server before backup, export,
restore, migration, or other work requiring exclusive access. Create and verify
a JSON backup, perform the prepared operation, verify schema state and critical
record counts, then restart and health-check the application. Prefer additive,
repeatable migrations and preserve the verified backup if maintenance fails.
Before the window, finish the code and idempotent migration, batch related
schema changes, identify verification queries, and run `npm run check` plus
`npm run build` while the server remains available. Prefer additive,
backward-compatible tables and safely defaulted or nullable columns. Coordinate
with known contributors so the stop does not interrupt an unsaved submission.
The offline window is deliberately narrow:
1. Inspect running processes and stop only this project's development server.
2. Run and verify `npm run db:backup`.
3. Run the already-prepared migration.
4. Verify expected schema state, record counts, and critical entities.
5. Restart the development server immediately.
6. Confirm a basic page or health check, then perform extended browser and
regression testing with the service online.
Code editing, builds, formatting, documentation review, and noncritical UI
testing do not belong inside this window. Destructive, data-rewriting, or
long-running migrations require a separately communicated maintenance window
and a verified recovery plan. Every migration handoff reports the backup path,
migration outcome, successful server restart, critical checks, and the
approximate offline interval when available.
Production and staging remain shared persistent environments and retain the
deployment, backup, synchronization, and maintenance safeguards documented in
`docs/DEPLOYMENT.md`.
# ISAC audit and compensating reversals