# KIP Interfaces — Release Specification v0.1.46 **Normative status:** Mandatory release gate. **Applies to every release from v0.1.33 forward.** ## Package structure and updater A distributable ZIP MUST contain exactly one current `KIP-Interfaces/` application tree and a complete `KIP-Interfaces-Updater/` sibling tree. The updater inventory MUST contain `install.php`, `lib/updater.php`, and `README.txt`; any additional updater runtime dependency MUST be included. An updater stub or merely `self-update.php` does not satisfy this requirement. The updater code MUST pass PHP syntax checks. Missing or inconsistent updater files are release-blocking. The external updater is an independently installed sibling of the application under `public_html`. Bundling it does not by itself install or upgrade the live external updater. Any updater upgrade MUST have a tested installation/rollback plan; never overwrite the running bootstrap without an independently verified recovery route. A release MUST NOT claim that bundled updater code was installed unless separately verified. ## Mandatory authoritative documentation `docs/Release-Specification.md`, `docs/System-Specification.md`, `docs/Functional-Specification.md`, `docs/User-Guide.md`, `docs/Administrator-Guide.md`, `docs/Installation-Updater-Guide.md`, `KIP-INTERFACES-INTEGRATION.md`, `docs/Development-Handoff.md`, `docs/Release-Notes-v.md`, and `docs/Release-Test-Report-v.md` MUST be included and reviewed for each release. Equivalent `.html` and `.docx` renditions of System Specification, User Guide and Development Handoff MUST be regenerated from the current markdown source, or explicitly removed with a documented migration plan; stale duplicates are forbidden. The integration specification MUST distinguish verified behavior from legacy/unverified endpoints. Every source change requires a documented impact review of user/admin guidance, architecture, API contracts, deployment, migration, security, and tests. Historical release reports remain immutable. ## CI-CONT-001 — Self-contained development continuity (mandatory release requirement) Every deployable release MUST include the complete, version-matched application source package and a documentation set sufficient for a new development session to resume work using **only that release package and its accompanying documents**, without access to earlier conversations, handoffs in external Libraries, or undocumented institutional knowledge. The packaged documentation MUST identify: (1) authoritative requirements with stable IDs, priorities, acceptance criteria and implementation status; (2) architecture, component responsibilities, interfaces, data formats, security and persistence constraints; (3) development decisions, assumptions, dependencies and known limitations; (4) source-to-requirement-to-test traceability and actual verification results, explicitly distinguishing PASS, FAIL, NOT RUN and NOT VERIFIED; (5) unresolved defects, backlog and next steps; (6) build, test, packaging, installation, update, rollback and recovery instructions; and (7) exact release identity, package hashes, predecessor relationship and source provenance. All normative references needed to interpret or continue development MUST be packaged in full or their relevant normative content incorporated into the packaged documentation. External links may be supplemental but MUST NOT be required to recover development state. Documents MUST be internally consistent, current for the packaged version, and regenerated across required Markdown/HTML/DOCX renditions. **Acceptance test:** Give an independent reviewer a clean workspace containing only the final release ZIP and its accompanying release documents. Without external chat or Library context, the reviewer MUST be able to identify the authoritative requirements and their status, locate implementation and tests, reproduce documented offline checks, identify unverified functionality and outstanding work, and prepare a justified next-development plan. Record a requirement-by-requirement evidence matrix, discrepancies, and an explicit PASS/FAIL decision bound to the final ZIP SHA-256. Missing, stale, contradictory, or externally dependent critical information is a release-blocking FAIL. A structural link check alone does not satisfy this test. **Current status (v0.1.46 development): NOT VERIFIED / BLOCKED.** No self-contained restart acceptance test has been completed; inherited specifications, requirements reconciliation, and handoff are known to need updates. Do not infer PASS from document presence. ## Version, manifest and provenance The release version, `config.php` system version, manifest release and specification versions, and current documentation release labels MUST agree. The manifest MUST include SHA-256 checksums for all packaged files, including the updater sibling files, except the manifest itself. The manifest MUST identify its accepted base version and base System Specification SHA-256. A version may not be republished with different bytes. Preserve accepted prior releases. ## Build and publication gates The repository build MUST execute `tools/validate-release.py` against the finished ZIP and reject failures. Check ZIP integrity, safe paths, mandatory files, updater contents, versions, document currency, duplicate rendition consistency, manifest coverage and checksums, and PHP syntax. Do not deliver, publish or deploy if any required gate fails. Manual exceptions require written approval and cannot be silently treated as PASS. Release evidence MUST distinguish static/package tests, behavior tests, upgrade tests, live tests, rollback tests, and user acceptance as PASS/FAIL/NOT RUN/PENDING. A passing static gate is not production acceptance. The release notes and test report MUST identify known defects and untested failure paths. Deployment engine and updater failure-path tests MUST pass before calling Stage 3 complete. ## Recovery and persistent data Preserve external persistent data, maintain a verified last-known-good package and rollback path, use unique temporary directories, verify backups before replacement, and check every critical filesystem operation. Never delete the only recovery copy before a new one has been verified. Interrupted installation and rollback must have independently exercised recovery tests before a deployment safety change is accepted. ## Permanent documentation traceability and release audit (historical requirement introduced in v0.1.37) The repository MUST include `docs/Documentation-Traceability.json` with stable requirement identifiers, authoritative documentation references, implementation evidence paths, and test references. The repository MUST include `tools/audit-documentation.py` which checks the traceability registry, required document presence, browser/Word renditions, source references, and release-version markers. The audit MUST produce `docs/Documentation-Audit-v.json` for each release, containing check outcomes, evidence and explicit unresolved items. A release MUST fail if structural checks, cross-reference checks, required renditions, or source-file references fail. Semantic correctness MUST NOT be claimed solely because paths or keywords match. Any critical claim lacking independent behavioral evidence must be marked `UNVERIFIED` and requires review or an approved exception. An audit with unresolved high-severity discrepancies MUST block publication. A current audit report and traceability registry are mandatory package contents. Each current primary document (User Guide, Administrator Guide, Installation and Updater Guide, System Specification, Functional Specification, Release Specification, Integration Specification, Development Handoff) MUST be available in `.md`, `.html`, and `.docx` form, built from the same Markdown source. HTML must be styled for comfortable browser reading and Word files must use heading styles, readable body typography and margins. Historical release records may remain in original format. ## Release evidence and testing links - [Acceptance Test Specification / Verification Plan](Verification-and-Acceptance-Plan.html) - [Release Test Report and linked individual results v0.1.46](Release-Test-Report-v0.1.46.html) - [Documentation Audit v0.1.46](Documentation-Audit-v0.1.46.html) - [Release Notes v0.1.46](Release-Notes-v0.1.46.html) Beginning **Phase 4**, the release must additionally link an **Automated Unit Test Specification** (test IDs, purpose, covered functions, expected results and execution instructions) and an **Automated Unit Test Report** (individual PASS/FAIL/SKIPPED/BLOCKED status, run time, environment and suite version). The unit-test framework and its reports are **not yet implemented**; do not present Phase 3 static checks as automated unit-test coverage. Acceptance tests, automated tests and user acceptance are separate records. The Release Specification links to evidence rather than embedding the acceptance basis in the Functional Specification. ## Historical release notes and development appendices Earlier checkpoint descriptions are retained in the versioned `Release-Notes-v0.1.41.md` through `Release-Notes-v0.1.44.md` and historical continuity records. They do not describe current v0.1.46 behavior. ## v0.1.46 mandatory blockers Do not release until browser updater migration, install/rollback tests, documentation semantic review, and user approval are complete.