Skip to content

README.md

Latest commit

 

History

History
56 lines (45 loc) · 3.03 KB

README.md

File metadata and controls

56 lines (45 loc) · 3.03 KB
Raw

Airlock engineering documentation

dev/ is the engineering record for Airlock. It explains why the product is shaped as it is and how current work is verified. It is not public operator documentation; start in ../docs/ for installation, configuration, and operations.

Start here

Need Canonical location
Product intent and acceptance criteria User needs
Testable product requirements Requirements
Runtime boundaries and design rationale Architecture
Approved semantic input-injection design Prompt-injection classifier design
Accepted refactoring direction Refactoring analysis
TUI test-maintenance methods and measured 0.5.15 outcome TUI test methods
Latest published release 0.5.12 plan, PII egress canary, and CHANGELOG
Next engineering backlog 0.5.14 TODO
OOM investigation instrumentation High-water runbook
How to operate the delivery harness Plans guide and harness runbook
Shipped behavior Public docs, CHANGELOG, and source/tests

Document lifecycle

Every engineering record is one of the following:

  • Active — defines work that is currently being implemented or verified.
  • Accepted — explains a shipped design decision; retain it as rationale.
  • Superseded — retained for history, but replaced by a linked newer record.
  • Archived — completed release plans, prompts, run evidence, and reviews.

Release work is indexed in plans/. The current release board is the only live status source. Completed-release artifacts remain in Git for auditability and are catalogued from the release archive index; do not treat their status language as current commitment.

Source-of-truth rules

  • airlock/ and tests/ define implemented behavior and regression coverage.
  • The shipped config.yaml template and .env.example define supported setup defaults; public docs explain how to use them.
  • The running proxy's /openapi.json and /airlock/docs define the live HTTP surface. The static API reference explains how to use that surface.
  • docs/ is canonical for users and operators. dev/ may link to it but must not duplicate it.

Maintaining the record

When a change affects users, operators, configuration, a response contract, or deployment, update the matching public page and its test in the same pull request. When it changes an accepted technical decision, link the design note to the implementation and targeted tests. At release closeout, mark the plan and its status board archived in the release archive index.