docs(governance): codify runtime resource boundaries

This commit is contained in:
DCCONSTRUCTIONS
2026-07-28 00:54:57 +03:00
parent 1c0181297d
commit 4a65b52f6d
+39
View File
@@ -24,6 +24,23 @@ and the boundary between Mission Core and vendor-specific integration code.
- Do not install or alter Homebrew/system components unless the user explicitly - Do not install or alter Homebrew/system components unless the user explicitly
authorizes that concrete change. authorizes that concrete change.
## Local operator resource envelope
- The operator Mac has 18 GB of physical memory. Treat local memory and swap as
a hard shared limit, not as disposable build capacity.
- Run frontend tests, production builds, Docker builds, runtime startup, and
browser QA sequentially. Do not launch parallel heavy local jobs.
- Do not run load or stress tests on the Mac. Run bounded synthetic load only on
Worker 006, and remove every temporary process after the measurement.
- Use only the canonical Mission Core endpoint on port `8000`; do not start
duplicate application servers to work around stale state.
- Before a memory-intensive local operation, inspect current memory pressure and
active Docker workload. Prefer focused tests and existing build artifacts when
they are sufficient for acceptance.
- Docker Desktop's configured VM ceiling is not evidence that the host can
safely supply that memory. Do not change Docker Desktop CPU or memory limits
without explicit owner approval.
## Evidence rules ## Evidence rules
- Reference inputs under `docs/reference/` are immutable; write corrections in - Reference inputs under `docs/reference/` are immutable; write corrections in
@@ -40,6 +57,28 @@ and the boundary between Mission Core and vendor-specific integration code.
Follow the gates in `docs/01_IMPLEMENTATION_PLAN.md`. Do not build heavy Follow the gates in `docs/01_IMPLEMENTATION_PLAN.md`. Do not build heavy
decoders before BLE/Wi-Fi/data-session evidence exists. decoders before BLE/Wi-Fi/data-session evidence exists.
## Docker runtime governance
- Every new or migrated durable NODE.DC-owned Docker container, Compose project,
network, named volume, and first-party image uses the lowercase `ndc-`
namespace. The prefix is mandatory for anything that may leave a laboratory
workstation; a legacy project/network name may survive only behind a bounded,
documented migration barrier.
- Do not retag or rename unrelated third-party runtime owned by another product.
Express NODE.DC ownership through the managed object name and
`com.nodedc.product`, `com.nodedc.stack`, `com.nodedc.role`, and
`com.nodedc.managed-by` labels.
- One operator-managed contour may be one Compose project while still using
separate single-purpose containers. Do not merge a broker, normalizer,
database, or application process into a multi-process container merely to
make Docker Desktop show one row.
- Treat Compose and worker orchestration declarations as the source of truth.
A live `docker rename` is allowed only as a bounded migration with exact
predecessor IDs, a persisted declaration change, rollback, and post-change
health acceptance.
- Keep bounded legacy-name fallback only for an explicit migration window.
New defaults, UI probes, runbooks, and durable runtime names must use `ndc-`.
## Product UI governance ## Product UI governance
- For every Control Station, LAB, viewer, or product-presentation change, use - For every Control Station, LAB, viewer, or product-presentation change, use