Bite 33.1 — Production Environment and Destructive‐Operation Guardrails - RodrigoMattosoSilveira/EnterpriseRemoteSystems GitHub Wiki

Bite 33.1 — Production Environment and Destructive-Operation Guardrails

Manual Verification Checklist Before Promotion

Branch: 928-bite-331-production-environment-and-destructive-operation-guardrails
Baseline SHA: 67125333f8dd16f3e34bfe9cf3d8bc9d22a9bbeb

1. Purpose

Bite 33.1 establishes a fail-closed Production environment boundary around destructive, demo, test, fixture, reset, and provisioning operations.

This manual verification confirms that:

  • Production destructive operations are refused before any data mutation occurs.
  • Missing or unknown environment identity cannot silently become Development.
  • Deployed environments require an explicit APP_ENV.
  • Deployment environment selection and runtime APP_ENV must agree.
  • Production cannot enable unsafe Development/Test runtime switches.
  • E2E/test administrator provisioning cannot run in Production.
  • Production administrator reset and Production volume deletion are blocked.
  • LOCAL, Development, Test, Brazilian demo, backup, and normal non-destructive workflows continue to function.

Because this Bite is primarily an operational/deployment safety Bite, several tests are necessarily terminal/configuration-driven rather than UI-driven.

2. Safety Rules for This Test Suite

Before starting:

  • Do not point destructive tests at a real Production database.
  • Use disposable paths under /tmp/ers-331-manual.
  • Do not substitute raw docker volume rm, raw rm, or equivalent unguarded commands for the ERS commands being tested.
  • When testing Production refusal, the objective is to verify that the guarded ERS workflow refuses the operation before mutation.
  • Record checksums where instructed so that database/file immutability can be proven.

Create the disposable test directory:

mkdir -p /tmp/ers-331-manual

3. Test 01 — LOCAL Development Still Starts Normally

Identity

Use an ordinary LOCAL ERS test identity.

Environment

LOCAL development.

Procedure

In Terminal 1:

unset APP_ENV
make local-backend

In Terminal 2:

make local-frontend

Open ERS in the browser using the normal LOCAL URL.

Sign in with an ordinary LOCAL test identity.

Navigate through at least:

  • Home/dashboard.
  • People.
  • Collaborators.

Expected Results

  • Backend starts successfully.
  • Frontend starts successfully.
  • LOCAL operation is not rejected merely because deployed APP_ENV is absent.
  • Authentication succeeds.
  • Normal LOCAL navigation works.

PASS Criteria

The ordinary LOCAL development workflow operates normally.

Promotion Blocker

Do not promote if Bite 33.1 prevents normal LOCAL development from starting or authenticating.

4. Test 02 — Explicit Production Destructive Database Reset Is Refused

Identity

No ERS login required.

Environment

Disposable local file with explicit APP_ENV=production.

Prerequisites

Create a sentinel database-like file:

mkdir -p /tmp/ers-331-manual

printf 'DO NOT DELETE\n' > /tmp/ers-331-manual/sentinel.db

shasum -a 256 /tmp/ers-331-manual/sentinel.db

Record its checksum:

Original checksum:

Procedure

Attempt the applicable destructive database reset command while identifying the environment as Production.

For example:

APP_ENV=production \
ERS_DATABASE_PATH=/tmp/ers-331-manual/sentinel.db \
make reset-db

Expected result The command should fail with:

Refusing SQLite database reset: Production data must not be modified by reset/demo/te

After the refusal, run:

cat /tmp/ers-331-manual/sentinel.db
shasum -a 256 /tmp/ers-331-manual/sentinel.db

Record:

Checksum after refused Production reset:

Expected Results

  • Command exits non-zero.
  • Output clearly indicates that Production destructive operation is refused.
  • /tmp/ers-331-manual/sentinel.db still exists.
  • Contents remain exactly:
DO NOT DELETE
  • Final SHA-256 checksum exactly matches the original checksum.

PASS Criteria

The Production refusal occurs before any database/file mutation.

Promotion Blocker

Do not promote if the Production-identified reset removes, truncates, recreates, changes, or otherwise mutates the sentinel file before failing.

5. # Test 03 — Missing Environment Fails Closed for Destructive Tooling

Purpose

Verify that destructive database tooling refuses to operate when APP_ENV is missing, even when an explicit disposable database path is supplied.

The database file must remain unchanged.

Identity

No ERS login required.

Environment

LOCAL terminal.

APP_ENV must be explicitly unset for this test.

Prerequisites

Create a disposable sentinel file:

mkdir -p /tmp/ers-331-manual

printf 'DO NOT DELETE\n' > /tmp/ers-331-manual/no-env.db

Record its checksum:

shasum -a 256 /tmp/ers-331-manual/no-env.db

Record:

Original checksum:

Confirm the file contents:

cat /tmp/ers-331-manual/no-env.db

Expected:

DO NOT DELETE

Procedure

Explicitly remove APP_ENV from the current shell:

unset APP_ENV

Confirm it is unset:

printenv APP_ENV

Expected:

(no output)

Now attempt the destructive database reset while supplying only the disposable database path:

ERS_DATABASE_PATH=/tmp/ers-331-manual/no-env.db \
make reset-db

Expected Result

The command must fail intentionally.

It must report that the destructive operation cannot proceed because a valid environment identity is required.

A non-zero Make exit status is expected.

The command must not delete or modify:

/tmp/ers-331-manual/no-env.db

Verify No Mutation Occurred

Run:

cat /tmp/ers-331-manual/no-env.db

Expected:

DO NOT DELETE

Then:

shasum -a 256 /tmp/ers-331-manual/no-env.db

Record:

Checksum after refused reset:

Compare it with the original checksum.

PASS Criteria

PASS only if all of the following are true:

  • APP_ENV was unset.
  • make reset-db exited non-zero.
  • The command reported that the destructive operation requires a valid environment identity.
  • /tmp/ers-331-manual/no-env.db still exists.
  • Its contents are still exactly DO NOT DELETE.
  • Its SHA-256 checksum is identical before and after the attempted reset.

Promotion Blocker

Do not promote Bite 33.1 if any of the following occurs:

  • make reset-db succeeds while APP_ENV is missing.
  • Missing APP_ENV is silently treated as Development or Test.
  • The sentinel database is deleted.
  • The sentinel database is truncated or otherwise modified.
  • The checksum changes before the guard rejects the operation.

6. # Test 04 — Unknown Environment Fails Closed

Purpose

Verify that destructive database tooling refuses to operate when APP_ENV contains an unsupported value.

The test proves that ERS does not silently interpret an unknown environment as Development or Test.

Identity

No ERS login required.

Environment

LOCAL terminal using a disposable sentinel database file.

Prerequisites

Create the disposable sentinel:

mkdir -p /tmp/ers-331-manual

printf 'DO NOT DELETE\n' > /tmp/ers-331-manual/unknown-env.db

Record its checksum:

shasum -a 256 /tmp/ers-331-manual/unknown-env.db

Record:

Original checksum:

Confirm the contents:

cat /tmp/ers-331-manual/unknown-env.db

Expected:

DO NOT DELETE

Procedure

Attempt the destructive database reset using an unsupported environment value:

APP_ENV=staging-ish \
ERS_DATABASE_PATH=/tmp/ers-331-manual/unknown-env.db \
make reset-db

Expected Result

The command must fail intentionally.

A non-zero Make exit status is expected.

The output must indicate that:

staging-ish

is not a recognized/supported ERS environment for destructive tooling.

The command must not treat staging-ish as:

development

or:

test

The file:

/tmp/ers-331-manual/unknown-env.db

must remain unchanged.

Verify No Mutation Occurred

Run:

cat /tmp/ers-331-manual/unknown-env.db

Expected:

DO NOT DELETE

Then:

shasum -a 256 /tmp/ers-331-manual/unknown-env.db

Record:

Checksum after refused reset:

Compare it with the original checksum.

PASS Criteria

PASS only if all of the following are true:

  • APP_ENV=staging-ish was supplied.
  • make reset-db exited non-zero.
  • ERS rejected staging-ish as an unsupported environment.
  • The command did not silently treat the value as Development or Test.
  • /tmp/ers-331-manual/unknown-env.db still exists.
  • Its contents remain exactly DO NOT DELETE.
  • Its SHA-256 checksum is identical before and after the attempted reset.

Promotion Blocker

Do not promote Bite 33.1 if any of the following occurs:

  • make reset-db succeeds with APP_ENV=staging-ish.
  • An unknown environment is silently treated as Development or Test.
  • The sentinel database is deleted.
  • The sentinel database is truncated or modified.
  • The checksum changes before the guard rejects the operation.

7. # Test 05 — Development and Test Destructive Tooling Remain Usable

Purpose

Verify that Bite 33.1 blocks destructive tooling only when it should.

The test proves that the guarded reset-db operation:

  • is permitted in development;
  • is permitted in test;
  • actually removes the explicitly selected disposable SQLite database;
  • does not globally disable legitimate non-Production reset workflows.

Identity

No ERS login required.

Safety Requirement

Use only the disposable files created in this test.

Do not point ERS_DATABASE_PATH at:

backend/data/app.db

or any Test/Production deployment database.

Part A — Development Reset Is Permitted

Prerequisites

Create a disposable Development database-like file:

mkdir -p /tmp/ers-331-manual

printf 'DELETE ME\n' > /tmp/ers-331-manual/dev-test.db

Confirm that it exists:

ls -l /tmp/ers-331-manual/dev-test.db

Confirm its contents:

cat /tmp/ers-331-manual/dev-test.db

Expected:

DELETE ME

Procedure

Run:

APP_ENV=development \
ERS_DATABASE_PATH=/tmp/ers-331-manual/dev-test.db \
make reset-db

Expected Result

The command should succeed.

It should report that the SQLite database was reset.

The file:

/tmp/ers-331-manual/dev-test.db

should no longer exist.

Verification

Run:

test ! -e /tmp/ers-331-manual/dev-test.db && echo "PASS: Development database removed"

Expected:

PASS: Development database removed

Also verify that no SQLite sidecars remain:

test ! -e /tmp/ers-331-manual/dev-test.db-wal && \
test ! -e /tmp/ers-331-manual/dev-test.db-shm && \
test ! -e /tmp/ers-331-manual/dev-test.db-journal && \
echo "PASS: Development SQLite sidecars removed"

Expected:

PASS: Development SQLite sidecars removed

Part B — Test Environment Reset Is Permitted

Prerequisites

Create another disposable file:

printf 'DELETE ME\n' > /tmp/ers-331-manual/test-test.db

Confirm:

ls -l /tmp/ers-331-manual/test-test.db
cat /tmp/ers-331-manual/test-test.db

Expected contents:

DELETE ME

Procedure

Run:

APP_ENV=test \
ERS_DATABASE_PATH=/tmp/ers-331-manual/test-test.db \
make reset-db

Expected Result

The command should succeed.

The file:

/tmp/ers-331-manual/test-test.db

should be removed.

Verification

Run:

test ! -e /tmp/ers-331-manual/test-test.db && echo "PASS: Test database removed"

Expected:

PASS: Test database removed

Then:

test ! -e /tmp/ers-331-manual/test-test.db-wal && \
test ! -e /tmp/ers-331-manual/test-test.db-shm && \
test ! -e /tmp/ers-331-manual/test-test.db-journal && \
echo "PASS: Test SQLite sidecars removed"

Expected:

PASS: Test SQLite sidecars removed

PASS Criteria

PASS only if all of the following are true:

  • APP_ENV=development allows make reset-db.
  • The explicitly selected Development disposable database is removed.
  • Its SQLite sidecar files are removed if present.
  • APP_ENV=test allows make reset-db.
  • The explicitly selected Test disposable database is removed.
  • Its SQLite sidecar files are removed if present.
  • No Production database or normal LOCAL database is touched.

Promotion Blocker

Do not promote Bite 33.1 if any of the following occurs:

  • make reset-db refuses a valid development environment.
  • make reset-db refuses a valid test environment.
  • The command targets a database other than the explicit ERS_DATABASE_PATH.
  • The command silently falls back to backend/data/app.db.
  • The command removes or modifies any database other than the disposable file supplied in the test.

8. Test 06 — Brazilian Demo Workflow Still Works

Identity

Use the Brazilian demo presenter identity:

Mariana Alves
[email protected]
Demo-31.4-Brasil!

Tenant:

Mineração Serra Dourada — DEMO
DEMO_BR_SERRA_DOURADA

Procedure

Run:

make brazilian-demo-local-reset
make brazilian-demo-local-verify
make brazilian-demo-presentation-check

Start the backend:

ERS_DATABASE_PATH=data/brazilian-demo.db make local-backend

In another terminal:

make local-frontend

Open ERS.

Sign in as:

[email protected]

using:

Demo-31.4-Brasil!

Confirm the selected Tenant is:

Mineração Serra Dourada — DEMO

Navigate through at least one normal Tenant Administrator page.

Expected Results

  • Demo database reset succeeds under LOCAL/Development identity.
  • Brazilian demo verification passes.
  • Presentation check passes.
  • Mariana can sign in.
  • The demo Tenant loads normally.
  • Bite 33.1 does not treat the LOCAL demo workflow as Production.

PASS Criteria

The deterministic Brazilian demo remains fully usable.

Promotion Blocker

Do not promote if Production hardening breaks the established LOCAL Brazilian demo workflow.

9. Test 07 — Production E2E Administrator Provisioning Is Refused

Identity

No ERS login required.

Procedure

Run:

make server-prod-provision-e2e-admin

Then search for the old Production override:

grep -R --line-number -- '--allow-production' \
  backend scripts Makefile .github docker-compose.server.yml

Expected Results

For make server-prod-provision-e2e-admin:

  • Command exits non-zero.
  • Output clearly states that E2E/test administrator provisioning is prohibited in Production.
  • No Production database mutation is attempted.

For the grep command:

  • No active E2E provisioning bypass remains.

PASS Criteria

There is no supported Production E2E administrator provisioning path.

Promotion Blocker

Do not promote if any supported flag, binary option, Make target, or deployment workflow can provision the E2E/test administrator into Production.

10. Test 08 — Production Volume Deletion Is Refused

Identity

No ERS login required.

Safety Requirement

Do not use raw Docker volume deletion commands.

Use only the guarded ERS target.

Procedure

Before the test, record ERS-related volumes:

docker volume ls

Record:

ERS data volume before test:

Run the guarded Production volume-removal target, for example:

make server-prod-down-volumes

If the patched Makefile uses a different Production destructive-volume target name, use that target.

After the refusal:

docker volume ls

Record:

ERS data volume after test:

Expected Results

  • Command exits non-zero.
  • ERS refuses the Production destructive-volume operation.
  • Docker volume destruction is not executed.
  • The ERS data volume remains present.

PASS Criteria

Production volume deletion cannot be reached through the supported ERS destructive workflow.

Promotion Blocker

Do not promote if the guarded Production target executes down -v, volume removal, or equivalent destructive behavior.

11. Test 09 — Production Administrator Reset Is Refused

Identity

No ERS login required.

Procedure

Run:

make server-prod-reset-admin

If the Makefile exposes a differently named guarded Production administrator-reset target, use that target.

Expected Results

  • Command exits non-zero.
  • Output clearly indicates that Production administrator reset is prohibited.
  • No administrator password/account/database mutation occurs.

PASS Criteria

Production administrator reset functionality is unavailable through supported ERS tooling.

Promotion Blocker

Do not promote if Production administrator credentials or records can be reset through the supported reset target.

12. Test 10 — Deployed Environment Cannot Omit APP_ENV

Identity

No ERS login required.

Prerequisites

Create a disposable copy of an existing non-secret server environment file.

For example:

cp backend/.env.production.example /tmp/ers-331-manual/no-app-env.env

Remove or comment out:

APP_ENV=...

from the disposable copy only.

Procedure

Render/validate the server Compose configuration using the disposable file:

docker compose \
  --env-file /tmp/ers-331-manual/no-app-env.env \
  -f docker-compose.server.yml \
  config

Expected Results

  • Compose/configuration fails.
  • Error indicates that APP_ENV is required.
  • The rendered configuration does not silently contain:
APP_ENV=development

PASS Criteria

A deployed environment must explicitly declare its runtime environment.

Promotion Blocker

Do not promote if missing APP_ENV silently becomes Development.

13. Test 11 — ENV and Deployed APP_ENV Mismatch Is Rejected

Identity

No ERS login required.

Prerequisites

Create a disposable server environment file containing:

APP_ENV=test

Procedure

Invoke the repository's deployed server validation/precheck workflow while selecting Production, for example:

make ENV=production <server-validation-target>

Use the actual validation/deployment-precheck target present in the patched Makefile.

The selected environment is therefore:

production

while the disposable environment file states:

test

If practical, repeat the inverse mismatch:

ENV=test
APP_ENV=production

Expected Results

  • Validation fails before deployment.
  • Error identifies the mismatch between selected deployment environment and configured runtime environment.
  • Deployment does not proceed.

PASS Criteria

Operator-selected deployment environment and configured APP_ENV must agree.

Promotion Blocker

Do not promote if mismatched environment identities are accepted.

14. Test 12 — Unsafe Production Runtime Switches Are Rejected

Identity

No ERS login required.

Safety Requirement

Use disposable Production-like configuration only.

Test each case independently.

Case A — APP_AUTO_MIGRATE

Configure:

APP_ENV=production
APP_AUTO_MIGRATE=true

Attempt backend startup or the applicable runtime configuration validation.

Expected

Startup/validation is refused.

Case B — Authorization Bypass

Configure:

APP_ENV=production
AUTHZ_DISABLE_ROUTE_AUTHORIZATION=true

Attempt backend startup or validation.

Expected

Startup/validation is refused.

Case C — Unsafe Actor Header Mode

If the patched runtime/deployment validation covers this value, configure:

APP_ENV=production
AUTHZ_ACTOR_HEADER_MODE=<unsafe-enabled-value>

Attempt startup/validation.

Expected

Startup/validation is refused.

Case D — Development Administrator Seed

Configure:

APP_ENV=production
DEV_SEED_ADMIN=true

Attempt startup/validation.

Expected

Startup/validation is refused.

PASS Criteria

Production cannot start with any prohibited Development/Test escape hatch enabled.

Promotion Blocker

Do not promote if any prohibited Production runtime switch is silently accepted.

15. Test 13 — Production Backup Remains Permitted

Identity

No ERS login required.

Purpose

Bite 33.1 must distinguish destructive operations from protective recovery operations.

Safety Requirement

Use a disposable Production-like database/configuration unless intentionally creating a legitimate Production backup.

Procedure

Run the repository's current Production backup target:

make ENV=production <server-backup-target>

Replace <server-backup-target> with the current backup target in the patched repository.

Expected Results

  • Production identity itself does not cause the backup operation to be rejected.
  • Backup completes according to existing behavior.
  • Bite 33.1 does not block recovery preparation.

PASS Criteria

Production backup remains available.

Promotion Blocker

Do not promote if the new guardrail mechanism prevents legitimate Production backup/recovery preparation.

16. Test 14 — scripts/init-env.sh Cannot Initialize Production

Identity

No ERS login required.

Prerequisites

Ensure this file does not already exist:

rm -f /tmp/ers-331-manual/generated-production.env

Procedure

Attempt to initialize an environment using the Production template:

scripts/init-env.sh \
  backend/.env.production.example \
  /tmp/ers-331-manual/generated-production.env

Then check:

ls -l /tmp/ers-331-manual/generated-production.env

If the file exists, inspect it:

cat /tmp/ers-331-manual/generated-production.env

Next, execute the normal Development initialization path using a disposable destination.

Expected Results

Production-template attempt:

  • Script refuses.
  • Production environment initialization is not performed.
  • A new Production environment file containing Development administrator seed credentials is not created.

Development/Test initialization:

  • The supported non-Production initialization workflow still succeeds.

PASS Criteria

The legacy Production-template + Development-seed path is eliminated while intended Development/Test initialization remains usable.

Promotion Blocker

Do not promote if scripts/init-env.sh can generate a Production environment containing Development/test administrator seeding or other unsafe defaults.

17. Test 15 — Full Automated Gate After Manual Verification

Procedure

Run:

make production-environment-guardrails-check
make production-release-evidence-check
make deployed-playwright-evidence-check
make brazilian-demo-presentation-check
make local-check

On the normal ERS workstation, which has the required SQLite tooling, also run:

make migration-rehearsal-check

Push the branch and allow CI to run.

Expected Results

  • Every local command above passes.
  • make local-check passes.
  • Migration rehearsal passes.
  • CI passes.

PASS Criteria

All automated gates are green after completion of the manual safety verification.

Promotion Blocker

Do not promote if any required local or CI gate fails.

18. Promotion Gate

Bite 33.1 is ready for promotion only when all of the following are true:

  • Production reset operations are refused before mutation.
  • Missing environment identity fails closed for destructive tooling.
  • Unknown environment identity fails closed for destructive tooling.
  • Development reset/fixture workflows continue to work where intentionally supported.
  • Test reset/fixture workflows continue to work where intentionally supported.
  • Brazilian demo reset, verification, and presentation workflow still works.
  • Production E2E administrator provisioning is impossible through supported tooling.
  • No active --allow-production E2E provisioning bypass remains.
  • Production administrator reset is refused.
  • Production volume destruction is refused.
  • Deployed environments require explicit APP_ENV.
  • Selected deployment environment and configured APP_ENV must agree.
  • Production rejects APP_AUTO_MIGRATE=true.
  • Production rejects AUTHZ_DISABLE_ROUTE_AUTHORIZATION=true.
  • Production rejects unsafe actor-header mode where applicable.
  • Production rejects DEV_SEED_ADMIN=true.
  • Production backup remains available.
  • scripts/init-env.sh cannot create unsafe Production configuration.
  • Normal LOCAL development still works.
  • make production-environment-guardrails-check passes.
  • make production-release-evidence-check passes.
  • make deployed-playwright-evidence-check passes.
  • make brazilian-demo-presentation-check passes.
  • make migration-rehearsal-check passes.
  • make local-check passes.
  • CI passes.

19. Highest-Priority Promotion-Blocking Scenarios

The following manual tests are especially important and should be treated as hard promotion gates:

  • Test 02 — Explicit Production destructive database reset is refused
  • Test 03 — Missing environment fails closed
  • Test 07 — Production E2E administrator provisioning is refused
  • Test 08 — Production volume deletion is refused
  • Test 10 — Deployed environment cannot omit APP_ENV
  • Test 12 — Unsafe Production runtime switches are rejected
  • Test 13 — Production backup remains permitted

Any failure in these scenarios is a Bite 33.1 promotion blocker.