# LawAxis Build Standards Manual

This document is the single standards manual for the current LawAxis suite build style.

It defines how the project is born, developed, frozen, promoted, and preserved.

## 1. Build Lifecycle

LawAxis uses one lifecycle model:

- `ZERO` means the canonical birth point for the build spine.
- `DEV` means local working versions that are allowed to change.
- `PROD` means the cloud release that is promoted after validation.

Lifecycle rule:

- Everything is born at `ZERO`.
- Work happens in `DEV`.
- Only validated versions are promoted to `PROD`.
- `PROD` is never the place where experimental work begins.

Public access rule:

- the suite landing page is the public front door
- `Roster` is reached from the landing page and then gates through sign-in
- authenticated roster work happens after the sign-in step, not before it

Command logging rule:

- a `Command` is one shell instruction or one logged operational step
- a `sub list` is each segment produced when a shell line is split by pipes, `&&`, `||`, semicolons, or similar separators
- Linux commands used during cloud/server work should be recorded in `COMMAND_LOG.md`
- log the command in the order it actually ran

## 2. Folder Roles

### `LawAxis_Pro`

`LawAxis_Pro` is the suite spine and Node Zero.

It is the authoritative source for:

- build language
- suite structure
- release discipline
- root manifests
- immutable baseline hashes

### `lawaxis_roster`

`lawaxis_roster` is a downstream working module.

It contains the roster product code, local admin portal, API, and module-specific notes.
It is the sign-in-gated operational module reached from the public landing page.

### `law_axis_db_builder`

`law_axis_db_builder` is the schema and SQLite build factory.

It generates the datasets, reports, relationship maps, and live database artifacts used by the suite.

### `current_live`

`current_live` is the active local database and report set.

Use it for validated current state, not as a casual scratch area.

### `version_checkpoints`

`version_checkpoints` holds historical snapshots.

Use it for recovery and comparison only.

### `COMMAND_LOG.md`

`COMMAND_LOG.md` is the running Linux command record for cloud/server setup and validation.

It should capture:

- the command
- its sub list segments
- why it was run
- what happened

## 3. Immutability Standard

The Node Zero spine is treated as frozen baseline material.

That means:

- do not casually edit the spine
- make intentional changes only
- refresh integrity hashes after any approved change
- prefer versioned replacement over silent drift

If a project needs a new direction, create a new versioned state rather than mutating the frozen spine without trace.

## 4. Naming Standard

The current best-practice naming pattern is:

- `ZERO` for the birth spine
- `DEV` for local working material
- `PROD` for cloud release material
- `current_live` for active validated local artifacts
- `version_checkpoints` for historical snapshots
- `archive` for retired outputs

Module names should be descriptive and stable.

## 5. Documentation Hierarchy

The canonical documentation set is:

- `STANDARDS.md` for the full lifecycle and build discipline
- `NODE_ZERO.md` for the spine rules
- `IMMUTABLE_MANIFEST.md` for integrity hashes
- `README.md` for quick orientation
- `manifests/LIVE_INDEX.md` for live artifact pointers
- `NOTES.md` in the working module for repair order and local operational notes

Rule:

- when the docs disagree, update the standards manual first and then align the rest of the docs to it

## 6. Promotion Path

The clean release path is:

1. Build or revise in the working module.
2. Validate locally.
3. Update notes and hashes.
4. Freeze the spine state.
5. Package the release.
6. Promote to cloud.
7. Preserve the promoted state as a versioned artifact.

Promotion rule:

- the cloud should receive a controlled release, not an undecided working tree
- live-server stress testing should happen against the promoted release path, not a hidden side branch

## 7. Evidence and Traceability

Every important build state should be traceable through one or more of these artifacts:

- file hashes
- live index entries
- version manifests
- relationship maps
- validation reports
- local notes
- checkpoint folders

Traceability rule:

- if someone asks "what is current," the answer should be discoverable from the live index and version manifest without guesswork
- command log entries should exist for Linux setup and validation steps

## 8. Accreditation-Oriented Build Discipline

This build style should support a future accreditation/manual structure by keeping:

- clear folder roles
- reproducible release state
- clear evidence paths
- versioned histories
- named artifacts instead of hidden state

Accreditation principle:

- one operational record should be reusable across modules when possible
- documentation should explain the chain from source build to deployed release
- evidence should remain attached to the exact version that produced it

## 9. Operating Summary

- `LawAxis_Pro` is the frozen Node Zero spine.
- `lawaxis_roster` is the working module.
- `law_axis_db_builder` is the data factory.
- `current_live` is the validated local live set.
- `version_checkpoints` preserve history.
- `PROD` is only for promoted releases.
- `COMMAND_LOG.md` is the running Linux command log.