# Update checklist

Use this for your own reviewed engine maintenance, not a routine paragraph edit or an instruction to change the pinned showcase. No command here performs a production deployment. Paths are illustrative; inspect actual installations and approve selected revision/return plan first.

# Baseline before any writes

Run inspection from the existing installation, preserving private output locally:

pwd
git rev-parse HEAD
git status --short
node --version
npm --version

Do not print all environment values into a support channel. Record safe path labels/configuration choices separately from secrets. A clean Git status does not prove ignored runtime/media is backed up. Never overwrite an active installation with an unreviewed clone.

# New disposable checkout

# First confirm this target does not exist or contain valuable files.
ls -ld MarkStackV2-next

# A separate new folder, not the live installation.
git clone https://github.com/KineticEnforcer/MarkStackV2.git MarkStackV2-next
cd MarkStackV2-next
git log -5 --oneline
git status --short

An expected “not found” from the first inspection does not authorize overwriting any other path. Stop if the destination exists unexpectedly. Inspect the selected revision using your review process and check out its exact approved commit before install. Branch head can change; cloning main is not a pin.

git rev-parse HEAD
node --version
npm ci
npm test

Use the new revision’s supported Node. Pinned handbook V2 requires 24+; a future revision’s requirements must be read. Install from its lockfile, retain actual result and do not proceed after failed install/tests. Tests alone do not prove your site’s compatibility or a production service restart.

# Transfer site inputs without engine overlay

This example assumes the old site is ../MarkStackV2 and the current directory is the new disposable checkout. Verify both, expected files and no useful pre-existing staging data. Stop on any mismatch. It keeps stock sample content aside rather than deleting it.

pwd
git rev-parse HEAD
ls -ld content ../MarkStackV2/content
ls -l ../MarkStackV2/siteconfig.json
ls -ld content.stock-before-site

Only after those inspections confirm the intended staged destination and unused aside name:

mv content content.stock-before-site
cp -a ../MarkStackV2/content ./content
cp -a ../MarkStackV2/siteconfig.json ./siteconfig.json

Check each exit/result before continuing. If copy fails, preserve the partial result for diagnosis; do not build it as complete or rerun over unknown state. Restore/prepare the disposable checkout deliberately.

cp -a is a Unix template. Windows/ACL/ownership differences need platform tools and checks. Do not copy .markstack into a public artifact/repository. Do not point a test editor at production accounts merely because it uses a new port. Account tools and normal saves can still affect shared files.

# Isolated build

For a staged checkout using default project content, make the build’s data/output choices explicit:

# Inspect the private staging-data folder and ensure output is disposable.
ls -ld /private-rehearsal/field-guide-data
ls -ld ./review-output

npm run build -- --data /private-rehearsal/field-guide-data --out ./review-output

The folder names are examples, not existing paths. Prepare a reviewed staging data copy before using them. Builder will remove/recreate selected output after route preflight; never use source/private data/project root as output. Selected content does not relocate installed templates/static/config.

Bundled npm run serve serves default dist, not this review-output. To use bundled preview in the staged checkout, build the intended default dist explicitly with the same data and check that disposable path first:

npm run build -- --data /private-rehearsal/field-guide-data
npm run serve

Alternatively serve the isolated artifact with your approved HTTP preview. Do not claim an old default output verified the new artifact. The public reader needs HTTP paths/resources, not file://.

# Staging acceptance

Test source, artifact and host separately. Inspect real pixels and browser requests; a build success or HTTP 200 is insufficient. Use synthetic staging accounts and fresh/existing browser contexts. Dependency updates need globals/loader/notices/browser-target review as well as npm tests.

# Cutover record before production

Name exactly what will switch: reader artifact, engine service, runtime or some combination. Agree the maintenance window, writer coordination, known compatible previous state and supported return procedure. Preserve last working code/output/private backup. Wait for publication completion before service/data replacement.

The operator executes the installed host/service procedure, then verifies actual live reader and editor as applicable. MarkStack does not automatically update DNS/TLS/proxies or restart a supervisor. Reader-only hosting needs no Node/editor process. Do not change authentication or account data for a static-only update.

# Return and close

Rollback uses the known prior compatible engine/config/source/runtime/artifact as required by the failed layer. Do not blindly overlay all old files or restore account state while newer writers run. Preserve failed evidence, coordinate writes and verify the actual returned public URL/perimeter.

Record selected revision, test/build/browser results, deployment identifier, observed URL and remaining limits. Resuming writers is a deliberate maintenance decision after acceptance. Keep retained backups private and remove disposable staging only after no useful evidence is lost.

This is a checklist/template, not an automated transactional updater or a claim that production account/service/host cutover was tested. See Upgrades and rollback, Backup and restore and Review and release.