v0.1.46 development draft: Historical requirement statements carried forward from v0.1.44. Proposed changes and acceptance are not implied.
Current status (v0.1.46): This is a retained 43-item historical backlog statement register. Refer to Requirements and Scope for the recovered PEND descriptions. Implementation status remains unverified unless supported by separate tests.
v0.1.46 — Package-contained Backlog Requirement Register
Status: SOURCE INVENTORY; NOT A VERIFIED REQUIREMENTS BASELINE.
This register assigns stable IDs to 43 bullet-level statements extracted verbatim from the packaged Development-Backlog.md in historical Checkpoint 11. The IDs identify backlog statements, not necessarily atomic requirements. Multi-clause statements require decomposition and acceptance criteria before closure. This register does not claim to recover unprovided historical requirements or demonstrate implementation.
Interpretation
- Origin: packaged Development Backlog; section heading retained.
- Candidate source: search starting point only; existence does not prove implementation.
- Implementation and acceptance: NOT VERIFIED unless separately backed by executed tests and review.
- Next action: classify, split composite statements, deduplicate against Phase 3 and PEND inventories, add measurable acceptance criteria and code/test evidence.
Backlog statements and candidate source locations
| ID | Source section | Verbatim backlog statement | Candidate source (not proof) | Status |
|---|---|---|---|---|
| BLG-001 | P0 — Complete and validate safe GitHub source-control path | Validate the live edit → preview → commit → explicit result → branch-specific verification workflow against Bluehost/GitHub. Every successful write must return the resulting commit SHA; failures must expose useful errors. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-002 | P0 — Complete and validate safe GitHub source-control path | Use optimistic concurrency/expected-HEAD protection. A write based on commit A must be rejected if the branch has moved to B. Never silently overwrite newer repository state. | Not mapped | NOT VERIFIED |
| BLG-003 | P0 — Complete and validate safe GitHub source-control path | Support AI-oriented source-control primitives: identify repository and branch, read files at exact revisions, retrieve branch HEAD, compare/diff revisions, create branches when permitted, and submit one or more files as an atomic commit. | Not mapped | NOT VERIFIED |
| BLG-004 | P0 — Complete and validate safe GitHub source-control path | Support reconciliation after stale-base rejection. KIP Interfaces supplies exact base/current content or diffs and safety checks; the AI performs development/merge reasoning. Any deterministic merge primitive must fail closed on conflicts. | Not mapped | NOT VERIFIED |
| BLG-005 | P0 — Complete and validate safe GitHub source-control path | Return machine-readable audit results for writes: repository, branch, expected/base commit, resulting commit, files changed, success/rejection, and useful error details. | Not mapped | NOT VERIFIED |
| BLG-006 | P0 — Complete and validate safe GitHub source-control path | Preserve GitHub credentials server-side. AI clients receive scoped KIP Interfaces authorization, never GitHub PATs. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-007 | P0 — Retained ZIP and synchronization | Finish live validation of retained-ZIP reuse across Compare, Initial Import, and Synchronize. One selected/uploaded server-retained package must be reusable without another browser file selection. | Not mapped | NOT VERIFIED |
| BLG-008 | P0 — Retained ZIP and synchronization | Redefine Synchronize as a controlled import/bootstrap operation, not a routine overwrite mechanism. Synchronization of an established repository must create an explicit Git commit with meaningful parentage and release identity. | tools/validate-release.py; release-manifest.json | NOT VERIFIED |
| BLG-009 | P0 — Retained ZIP and synchronization | Before synchronization/import, compare against current GitHub HEAD and reject unsafe overwrite when repository state has moved unexpectedly. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-010 | P0 — Retained ZIP and synchronization | Longer term, de-emphasize Synchronize or place it behind an administrative/advanced path. Normal ongoing development should be source-control based; every change to an established repository should be explainable by a commit. | Not mapped | NOT VERIFIED |
| BLG-011 | P0 — Version-state awareness and documentation integrity | Add version-state awareness that distinguishes at least: installed/deployed version, GitHub repository version, and latest generated/retained release. Show drift clearly without automatically labeling a legitimate state as defective. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-012 | P0 — Version-state awareness and documentation integrity | Expose version-state information in the administrative/status UI and make it machine-readable where useful. | Not mapped | NOT VERIFIED |
| BLG-013 | P0 — Version-state awareness and documentation integrity | Validate documentation content coherently against the release/specification/base-version identities. A package fingerprint alone does not prove document content is current. | index.php; tools/build-documentation.py; tools/check-document-links.py | NOT VERIFIED |
| BLG-014 | P0 — Version-state awareness and documentation integrity | Reclassify the previously observed one-version-behind documentation case when GitHub itself was behind: displaying GitHub's actual older state is correct; the missing capability is drift reporting. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-015 | P1 — Product scope reset: AI-to-GitHub bridge, not an IDE | Define KIP Interfaces primarily as a narrow, controlled, AI-agnostic bridge between AI clients and GitHub/source control. Do not evolve it into an online IDE or Visual Studio replacement. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-016 | P1 — Product scope reset: AI-to-GitHub bridge, not an IDE | Retain useful human UI for visibility, administration, diagnostics, and oversight, including repository/branch selection and the existing branch/commit visualization. | Not mapped | NOT VERIFIED |
| BLG-017 | P1 — Product scope reset: AI-to-GitHub bridge, not an IDE | Validate the existing file viewer against the narrowed requirement. Keep a simple general-purpose preview for README/Markdown, text/source inspection, images/drawings when supported, and downloads. Do not require syntax-aware editing, language intelligence, or IDE navigation. | Not mapped | NOT VERIFIED |
| BLG-018 | P1 — Product scope reset: AI-to-GitHub bridge, not an IDE | Diff is primarily an API/source-control primitive for AI reasoning and safety; a sophisticated graphical diff UI is not required. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-019 | P1 — Product scope reset: AI-to-GitHub bridge, not an IDE | Preserve accurate Git branch semantics in visualization: branches are pointers to commits, not copied file trees; external branches remain usable. | Not mapped | NOT VERIFIED |
| BLG-020 | P1 — AI API discovery and multi-client compatibility | Add a capability/metadata endpoint so an AI client can discover API version, supported operations, authorized repositories, read/write permissions, limits, and relevant capabilities. | admin.php; client.php | NOT VERIFIED |
| BLG-021 | P1 — AI API discovery and multi-client compatibility | Provide a human-readable website view of the same capability metadata, generated from the same underlying definition so UI and API cannot drift. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-022 | P1 — AI API discovery and multi-client compatibility | Verify the existing authentication model can support multiple external AI clients with scoped credentials/permissions. Keep one stable API rather than ChatGPT-specific behavior. | admin.php; client.php | NOT VERIFIED |
| BLG-023 | P1 — AI API discovery and multi-client compatibility | Add a future cross-AI acceptance test: use a second AI client such as Grok or another available client to perform a small read/modify/commit task through the same API contract. | admin.php; client.php | NOT VERIFIED |
| BLG-024 | P1 — Authoritative deployment-state interface | Add or define a separate Tilted Logic deployment/site-management interface rather than expanding GitHub functions into deployment management. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-025 | P1 — Authoritative deployment-state interface | Provide direct authoritative inspection of deployed server state instead of relying on public web retrieval/search caches. Return file manifest information such as paths, sizes, hashes, version identity, and when available the source commit/release that produced the deployment. | tools/validate-release.py; release-manifest.json | NOT VERIFIED |
| BLG-026 | P1 — Authoritative deployment-state interface | Support deterministic validation: compare intended source/release against actual deployed server files, deploy, validate the resulting state, and record the source commit/release. | tools/validate-release.py; release-manifest.json | NOT VERIFIED |
| BLG-027 | P1 — Authoritative deployment-state interface | Architectural rule: public web visibility is not proof of deployed state when an authoritative deployment-state interface exists. | Not mapped | NOT VERIFIED |
| BLG-028 | P1 — Domain Manifest system | Create a Domain Manifest concept: a machine-readable bootstrap/index describing what resources, datasets, files, API endpoints, schemas, capabilities, versions, links, and domain-specific operating instructions are available and which are authoritative. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-029 | P1 — Domain Manifest system | Create a Domain Manifest Registry inside the Interfaces infrastructure. It must create/register, discover/list, retrieve, update, and version manifests without hard-coded per-domain endpoints in AI clients. | self-update.php; lib/release-approval.php; KIP-Interfaces-Updater/lib/updater.php | NOT VERIFIED |
| BLG-030 | P1 — Domain Manifest system | Provide one well-known stable bootstrap address for the registry. From it, clients discover domains such as KIP Apiary, Mars, Greenhouse, Garden, and Embedded Systems. | admin.php; client.php | NOT VERIFIED |
| BLG-031 | P1 — Domain Manifest system | Define and version the Domain Manifest schema. Include stable domain identity, description, manifest/schema version, operating instructions, resources/endpoints, authority indicators, and access requirements. | Not mapped | NOT VERIFIED |
| BLG-032 | P1 — Domain Manifest system | Validate manifests on create/update so malformed manifests cannot strand a domain. Retrieval must identify the exact manifest version/hash used. | self-update.php; lib/release-approval.php; KIP-Interfaces-Updater/lib/updater.php | NOT VERIFIED |
| BLG-033 | P1 — Domain Manifest system | Support permissions: a manifest may describe resources that a particular AI is not authorized to use; Interfaces must enforce access rather than relying on the client. | admin.php; client.php | NOT VERIFIED |
| BLG-034 | P1 — Domain Manifest system | Move domain-specific AI setup instructions out of global/project ChatGPT setup and into the appropriate registered Domain Manifest. Global setup should shrink to the bootstrap rule for discovering/loading the current domain manifest. | Not mapped | NOT VERIFIED |
| BLG-035 | P1 — Domain Manifest system | For KIP Apiary specifically, migrate the current sources/project bootstrap material and operating instructions into or behind the KIP Apiary Domain Manifest. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-036 | P2 — KIP/project-state integration boundary | Do not turn KIP Interfaces into the project knowledge-management system. KIP owns durable domain/project knowledge and state; GitHub owns source history; KIP Interfaces safely connects AI to GitHub and other interface services. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-037 | P2 — KIP/project-state integration boundary | Future KIP project state should preserve objectives, current state, backlog, decisions and rationale, feature lifecycle/history, open questions, and significant changes. These requirements belong to KIP, not the KIP Interfaces implementation. | Not mapped | NOT VERIFIED |
| BLG-038 | P2 — KIP/project-state integration boundary | Design machine-readable write/deployment results so KIP can later capture source-control and deployment events as project history. | Not mapped | NOT VERIFIED |
| BLG-039 | Acceptance gates | Do not declare Phase 2 complete until live commit execution/result reporting and retained-ZIP reuse pass on the server. | Not mapped | NOT VERIFIED |
| BLG-040 | Acceptance gates | After API primitives are implemented, verify stale-base rejection, diff/reconciliation flow, atomic multi-file commit, and exact resulting SHA. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-041 | Acceptance gates | Verify version-state display with deliberately different installed, GitHub, and retained/latest versions. | github.php; lib/github.php; ai-api.php; lib/ai-api.php | NOT VERIFIED |
| BLG-042 | Acceptance gates | Verify Domain Manifest discovery from the single registry bootstrap address, exact version/hash reporting, validation failure behavior, and permission enforcement. | Not mapped | NOT VERIFIED |
| BLG-043 | Acceptance gates | Later, perform cross-AI compatibility testing through the same API contract. | ai-api.php; lib/ai-api.php | NOT VERIFIED |
Outstanding inventory crosswalk
PEND-001throughPEND-061: retained as unresolved identifiers, not assumed equivalent to BLG rows; the packaged reconciliation contains only mention counts, not authoritative descriptions.- Ten
P3-*identifiers: described inRequirements-Reconciliation-v0.1.41.md; overlap with backlog statements is unresolved. - Six inherited traceability entries: still
INHERITED_UNRECONCILED. CI-CONT-001: mandatory package-continuity acceptance, independently untested.CI-UPD-001: high-severity release approval issue, open.
How to complete the register
For each row, provide an atomic normative requirement, priority, acceptance criterion, current implementation state, source symbol and line range, executable test case and observed result. Record external-only historical evidence as MISSING until its normative substance is included in the release package. Do not close a requirement solely because a file exists.