vwiebe/conductor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add project planning and session state

Browse Source
This commit is contained in:
Victor Wiebe 2026-07-18 10:42:43 -04:00
parent cce97392f7
commit aa9cfb4ff0
9 changed files with 743 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

183
CODEX.md Normal file
View File

@ -0,0 +1,183 @@
# Codex Project State
This file is the durable handoff record for Codex sessions working on Conductor. Read it before making changes, verify any drift against the current code, and update it at the end of each material work session.
## Project
Conductor is a web-based, low-code builder for creating simple user interfaces backed by REST API endpoints. Its initial use case is IBM Concert Workflows / Rapid Infrastructure Automation, but the application must remain backend-agnostic.
Repository:
- Remote: `https://gitea.skeletonworks.online/vwiebe/conductor.git`
- Primary branch: `main`
- Workspace: `/home/vwiebe/projects/conductor`
- Initial fork commit: `cce97392f72049007cf00b0aa6c77fb8c8256191`
## Sources of Truth
Use these files in this order:
1. Current source code and automated tests
2. `TASKS.md` for completed and remaining work
3. `docs/response-mapping-model.md` for response-binding decisions
4. `shared/schemas/conductor-project.schema.json` for the accepted project-document shape
5. `docs/REQUIREMENTS.md` for product scope
6. `docs/ARCHITECTURE.md` for architectural direction
7. `docs/BUILD_AND_TEST_PLAN.md` for historical milestone and validation guidance
Some root-level documentation duplicates files under `docs/`. The `docs/` copies should become authoritative, but that cleanup has not yet been completed.
## Core Architectural Decisions
- The canonical source of truth is one versioned JSON project document.
- The Visual Editor, JSON Editor, Preview runtime, persistence layer, validation, and future AI tooling must operate on the same canonical document.
- Runtime state must remain separate from the canonical document.
- Projects are persisted in SQLite for the MVP.
- External REST requests must flow through the backend proxy.
- Secrets must never be intentionally exposed to the browser or stored in exported project JSON.
- Top-level `project.bindings` is the canonical data-flow mechanism.
- `action.responseMapping` is deprecated and must not be used for new behavior.
- New action-response bindings should use `onSuccess`; legacy `onClick` response bindings remain compatible.
- Production deployment should use an external reverse proxy.
- Conductor must remain functional without AI services.
## Current Implementation State
### Foundation
- React and TypeScript frontend
- Node.js, Express, and TypeScript backend
- SQLite database initialization and project persistence
- Project CRUD API
- Health and validation endpoints
- Dockerfiles and Docker Compose configuration
- Application layout, navigation, and shared project context
- Project creation, save, update, and load controls
### Project model and editing
- Canonical project JSON model at schema version `0.1.0`
- Shared JSON schema and frontend TypeScript types
- Backend schema validation
- Valid and intentionally invalid example project definitions
- Visual Editor and JSON Editor operating on shared project state
- JSON syntax and schema validation before JSON Editor changes are applied
### Active GUI components
The following components are available in the palette and have canvas, property-editor, and Preview support:
- Label
- Button
- Text Input
- Dropdown
- Table
- JSON Viewer
The following MVP component types are accepted by the schema but are not active in the Visual Editor or Preview:
- Text Area
- Checkbox
- Radio Group
- Status/Message Panel
- Container/Card
### REST and Preview runtime
- REST action model supporting GET, POST, PUT, PATCH, and DELETE
- Anonymous server-side REST execution
- Request URL, header, query, path, and body templates
- Normalized proxy response envelope
- Button-triggered action execution in Preview
- Runtime component, action, and variable state
- Response mappings to Label and JSON Viewer values
- Response mappings to Dropdown options
- Response mappings to Table rows
- Response mappings to project variables
- Table row selection
- Binding and action diagnostics
- Frontend unit tests covering templates, bindings, variables, dropdowns, and tables
## Known Gaps and Risks
- Basic, Bearer, and API-key authentication types are modeled but currently execute anonymously.
- Secure credential storage and secret resolution are not implemented.
- The REST proxy still needs endpoint allowlisting, SSRF protection, and stricter header and URL validation.
- Sanitized execution history and troubleshooting views are not implemented.
- Visual REST action, event, and binding configuration workflows are incomplete; advanced configuration still relies on JSON editing.
- Project documents are validated in the JSON Editor, but save operations still need an unconditional validation gate.
- The schema accepts five component types that the editor and runtime cannot render.
- Backend and end-to-end automated test coverage remains incomplete.
- The requirements include IBM Bob/watsonx in MVP scope, while the architecture permits operation without AI. The release requirement still needs a decision.
- Root-level requirement and architecture documents duplicate files under `docs/` and may drift.
## Validation Status
The initial repository push was completed on 2026-07-18.
- Remote `main` contains commit `cce97392f72049007cf00b0aa6c77fb8c8256191`.
- The working tree was clean immediately after the push.
- All `:Zone.Identifier` sidecar files were removed before the initial commit.
- Frontend tests, frontend build, and backend build were attempted before the push but could not start because dependencies were not installed locally (`react-scripts` and `tsc` were unavailable).
- Do not treat the current codebase as freshly validated until dependencies are installed and the validation suite is run.
## Immediate Priorities
Unless the user chooses a different priority, proceed in this order:
1. Install dependencies using the repository lockfiles and run the existing validation suite.
2. Record genuine failures separately from environment/setup failures.
3. Implement the five missing MVP GUI components individually, with tests.
4. Add visual REST action, event, and binding configuration.
5. Add validation to every project save path.
6. Implement authentication and secure secret handling.
7. Harden the REST proxy and add sanitized execution logging.
8. Add backend and end-to-end tests, then complete Docker Compose validation.
9. Resolve the AI-in-MVP scope decision.
10. Reconcile and consolidate project documentation.
See `TASKS.md` for the complete actionable checklist.
## Working Conventions
- Keep the canonical schema, frontend types, backend validation, examples, editor, and runtime synchronized.
- Any project-model change must include schema validation of valid and invalid examples.
- Prefer small, focused changes with tests over broad rewrites.
- Do not execute deprecated `action.responseMapping` rules.
- Do not store runtime values in canonical project JSON.
- Do not commit secrets, environment files, SQLite databases, dependency directories, or build artifacts.
- Preserve backend-agnostic REST behavior; do not couple core runtime logic to IBM-specific services.
- Clearly distinguish implemented behavior from schema-only or planned behavior.
- Update `TASKS.md` when a task is completed, added, removed, or materially re-scoped.
## Session Start Checklist
At the beginning of a new session:
- [ ] Read `CODEX.md` and `TASKS.md`.
- [ ] Run `git status --short --branch`.
- [ ] Inspect recent commits with `git log --oneline -5`.
- [ ] Verify relevant source files before relying on this handoff; this document may lag behind code.
- [ ] Confirm the selected task and its acceptance criteria.
- [ ] Run focused baseline tests when dependencies are available.
## Session End Checklist
After material work:
- [ ] Update completed and remaining items in `TASKS.md`.
- [ ] Update the implementation state, gaps, validation status, and next priority in `CODEX.md`.
- [ ] Record the exact commands run and whether they passed when validation results materially changed.
- [ ] Ensure documentation matches any schema or runtime decisions made during the session.
- [ ] Report modified files, tests, builds, and unresolved blockers to the user.
## Latest Handoff
Date: 2026-07-18
- Reviewed the documentation and current source implementation.
- Created `TASKS.md` with completed work and remaining MVP tasks.
- Removed 99 Windows `:Zone.Identifier` sidecar files.
- Initialized the fork as a new Git repository and pushed `main` to Gitea.
- Created this cross-session state file.
- Next recommended action: install dependencies and establish a clean validation baseline before implementing the next MVP feature.

68
SLICE1.md Normal file
View File

@ -0,0 +1,68 @@
# Slice 1: Remaining MVP GUI Components
## Status
Not started
## Objective
Implement every GUI component required by the MVP so each schema-supported component can be added, configured, rendered, used in Preview, and tested.
## Dependencies
- Existing canonical schema, component model, palette, canvas, property editor, and Preview patterns
- Slice 7 is required only if the AI decision changes component-generation scope
## In Scope
- Text Area, Checkbox, Radio Group, Status/Message Panel, and Container/Card
- Defaults, property controls, runtime behavior, bindings, diagnostics, examples, and tests
## Out of Scope
- Post-MVP widgets such as tabs, modals, charts, and file upload
- Visual action and binding authoring, which belongs to Slice 2
## Tasks
- [ ] Define shared acceptance criteria and test patterns for component implementation.
- [ ] Implement Text Area end-to-end.
- [ ] Implement Checkbox end-to-end.
- [ ] Implement Radio Group end-to-end.
- [ ] Implement Status/Message Panel end-to-end.
- [ ] Define and implement the minimum MVP Container/Card behavior and nesting rules.
- [ ] Add component-specific binding support and diagnostics.
- [ ] Add or update example projects for all five components.
- [ ] Remove the schema/runtime mismatch for supported component types.
- [ ] Update `TASKS.md`, `CODEX.md`, and relevant documentation.
## Acceptance Criteria
- [ ] All eleven MVP types can be added through the palette and render on the canvas and in Preview.
- [ ] Properties survive JSON editing and save/load round trips.
- [ ] Interactive values remain in runtime state, not canonical JSON.
- [ ] Invalid configurations produce useful diagnostics.
- [ ] Existing components and bindings continue to work.
## Validation
- [ ] Frontend TypeScript check and production build pass.
- [ ] Component and renderer tests pass.
- [ ] Schema examples validate as expected.
- [ ] Manual canvas, Preview, and save/load checks pass for each component.
## Risks and Open Questions
- Container/Card needs a deliberately small nesting contract.
- Checkbox and Radio Group values must stay consistent across properties, runtime, templates, and bindings.
- Status/Message Panel needs a distinct contract from Label and JSON Viewer.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Define component contracts and implement Text Area as the reference pattern.
- Known blockers: Container/Card nesting behavior requires a scoped decision.

72
SLICE2.md Normal file
View File

@ -0,0 +1,72 @@
# Slice 2: Visual Configuration
## Status
Not started
## Objective
Allow an MVP project to be configured through the GUI without routine hand-editing of canonical JSON.
## Dependencies
- Slice 1 component contracts
- Existing action, event, binding, variable, and Preview models
- Canonical top-level `project.bindings` decision
## In Scope
- Visual REST Action CRUD
- Component events, request input mappings, response bindings, variables, and page-load configuration
- Immediate synchronization with canonical project JSON
## Out of Scope
- AI-generated configuration
- Chained actions, general orchestration, and advanced JSONPath authoring
## Tasks
- [ ] Design a consistent workflow for editing actions, events, bindings, and variables.
- [ ] Implement REST Action list, create, edit, duplicate, and delete operations.
- [ ] Add method, URL, headers, query, path, body, timeout, and authentication-type controls.
- [ ] Implement component event configuration, beginning with Button `onClick`.
- [ ] Implement request input mapping from components and variables.
- [ ] Implement response source and component/variable target selection.
- [ ] Default new action-response bindings to `onSuccess`.
- [ ] Implement page-load action configuration for initial data population.
- [ ] Add variable declaration and default-value editing.
- [ ] Warn before deleting referenced actions, variables, or components.
- [ ] Ensure every visual edit immediately updates canonical JSON.
- [ ] Add tests, examples, and documentation updates.
## Acceptance Criteria
- [ ] A user can build the workflow launcher without editing JSON.
- [ ] Actions, inputs, triggers, and response mappings can be configured visually.
- [ ] Initial dropdown/table population can be configured visually.
- [ ] Dangling references are reported before Preview execution.
- [ ] Visual and JSON editors remain synchronized and save/load preserves configuration.
## Validation
- [ ] Frontend TypeScript check and production build pass.
- [ ] Editor interaction tests pass.
- [ ] Generated canonical JSON validates against the schema.
- [ ] Manual workflow-launcher and dependent-data scenarios pass.
## Risks and Open Questions
- Configuration UI needs progressive disclosure to remain manageable.
- Page-load support must not become a general workflow engine.
- Authentication controls must reference secrets without storing credential values.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Design the action editor data flow and acceptance-test project.
- Known blockers: Coordinate secret-reference fields with Slice 3.

71
SLICE3.md Normal file
View File

@ -0,0 +1,71 @@
# Slice 3: Authentication and Secrets
## Status
Not started
## Objective
Execute every MVP authentication type securely without exposing credentials to the browser or canonical project exports.
## Dependencies
- Existing REST proxy and authentication-type model
- Slice 2 authentication UI contract
- Deployment decision for secret provisioning
## In Scope
- Basic, Bearer, API-key header, API-key query, and anonymous authentication
- Server-side secret references, storage, resolution, redaction, and lifecycle
## Out of Scope
- OAuth 2.0, IBM Cloud IAM, mTLS, and arbitrary authentication scripts
## Tasks
- [ ] Define the MVP secret-reference model and threat assumptions.
- [ ] Select and document the server-side secret storage mechanism.
- [ ] Ensure project JSON contains references and metadata only.
- [ ] Implement safe secret create, update, lookup, and delete APIs.
- [ ] Implement Basic authentication injection.
- [ ] Implement Bearer token injection.
- [ ] Implement API-key header injection.
- [ ] Implement API-key query-parameter injection.
- [ ] Reject missing or incompatible references with structured errors.
- [ ] Redact credentials from logs, errors, history, and frontend responses.
- [ ] Exclude secrets from export and project CRUD responses.
- [ ] Add authentication, failure, and redaction tests.
- [ ] Update state, deployment, and security documentation.
## Acceptance Criteria
- [ ] All five modeled authentication modes execute as documented.
- [ ] Browser-visible traffic and exported JSON never contain stored credentials.
- [ ] Logs and errors redact sensitive values.
- [ ] Missing or invalid secret references fail safely and clearly.
- [ ] Secrets survive the intended MVP deployment lifecycle.
## Validation
- [ ] Backend TypeScript check passes.
- [ ] Authentication and redaction tests pass.
- [ ] Controlled mock-endpoint checks pass.
- [ ] Docker Compose secret provisioning and restart checks pass.
## Risks and Open Questions
- Plaintext secrets in SQLite require an explicit and acceptable MVP policy.
- Query API keys require special URL redaction.
- Secret ownership is limited in a single-user MVP.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Write the threat model and select the MVP secret store.
- Known blockers: Secret storage and deployment policy need an explicit decision.

67
SLICE4.md Normal file
View File

@ -0,0 +1,67 @@
# Slice 4: Proxy Security
## Status
Not started
## Objective
Harden the REST proxy against unsafe destinations, header abuse, credential leakage, and resource exhaustion while retaining backend-agnostic REST support.
## Dependencies
- Slice 3 credential injection and redaction model
- Existing proxy response contract and deployment configuration
## In Scope
- Destination policy, SSRF defenses, request controls, sanitized observability, and execution history
## Out of Scope
- Application RBAC, enterprise SIEM integration, and arbitrary user scripting
## Tasks
- [ ] Document the proxy threat model and default-deny boundaries.
- [ ] Define permitted origins, hosts, schemes, and ports.
- [ ] Block unsafe local, link-local, metadata-service, and unapproved destinations.
- [ ] Revalidate DNS results and redirect targets.
- [ ] Permit only HTTP and HTTPS.
- [ ] Allowlist request headers and strip dangerous or hop-by-hop headers.
- [ ] Add request, response, redirect, and timeout limits.
- [ ] Standardize safe proxy error responses.
- [ ] Persist sanitized execution metadata and bounded previews.
- [ ] Add execution-history retrieval for troubleshooting.
- [ ] Add adversarial and regression tests.
- [ ] Update state, deployment, and security documentation.
## Acceptance Criteria
- [ ] Forbidden destinations cannot be reached directly or through DNS/redirect bypasses.
- [ ] Credentials cannot be forwarded to unintended origins.
- [ ] Unsafe headers and oversized traffic are rejected predictably.
- [ ] Logs and history remain useful without containing secrets.
- [ ] Approved external and internal APIs work through explicit policy.
## Validation
- [ ] Backend TypeScript check passes.
- [ ] Proxy security, SSRF, redirect, timeout, and size-limit tests pass.
- [ ] Docker Compose policy configuration is verified.
## Risks and Open Questions
- Internal enterprise APIs require an explicit exception to private-network blocking.
- Redirects and DNS resolution need validation at each boundary.
- Execution previews need strict redaction and size limits.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Define destination-policy configuration and threat-model tests.
- Known blockers: Decide how approved internal hosts are represented.

73
SLICE5.md Normal file
View File

@ -0,0 +1,73 @@
# Slice 5: Validation and Error Handling
## Status
Not started
## Objective
Reject invalid project definitions consistently and explain editor, persistence, and Preview failures clearly without losing user work.
## Dependencies
- Canonical schema and backend validator
- Slice 1 component contracts and Slice 2 visual configuration model
- Slice 3 and 4 structured security errors for final integration
## In Scope
- Validation on every persistence path
- Cross-reference and semantic validation
- Editor and Preview diagnostics
- Structured backend errors and safe recovery
## Out of Scope
- AI remediation, arbitrary transforms, and enterprise audit workflows
## Tasks
- [ ] Inventory validation behavior across JSON Apply, create/update, load, and Preview.
- [ ] Centralize backend schema validation and reuse it on every save path.
- [ ] Reject invalid documents without partial persistence updates.
- [ ] Add supported schema-version checks.
- [ ] Validate duplicate IDs/names and dangling action, component, variable, event, and binding references.
- [ ] Validate component-specific properties and binding target compatibility.
- [ ] Standardize backend error codes and response shapes.
- [ ] Surface errors in visual configuration screens and the JSON Editor.
- [ ] Add Preview loading, empty, upstream-error, mapping-error, and recovery states.
- [ ] Preserve unsaved edits when validation or network operations fail.
- [ ] Reconcile examples with canonical binding behavior.
- [ ] Add malformed, semantic, version, and recovery regression tests.
- [ ] Update state and validation documentation.
## Acceptance Criteria
- [ ] No create or update path persists an invalid canonical document.
- [ ] Errors identify actionable paths and messages.
- [ ] Visual Editor, JSON Editor, backend, and Preview agree on supported shapes.
- [ ] Runtime failures are visible without corrupting project or runtime state.
- [ ] Valid examples continue to round-trip.
## Validation
- [ ] Frontend and backend TypeScript checks pass.
- [ ] Validator unit and route tests pass.
- [ ] Valid examples pass and invalid examples fail as expected.
- [ ] Save/load rollback and manual error scenarios pass.
## Risks and Open Questions
- JSON Schema cannot express all semantic rules.
- Severity must distinguish blocking errors from warnings.
- Pre-stable `0.x` documents need a compatibility policy.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Build a validation matrix for every entry point and error class.
- Known blockers: Define unsupported schema-version behavior.

70
SLICE6.md Normal file
View File

@ -0,0 +1,70 @@
# Slice 6: Testing and Release Validation
## Status
Not started
## Objective
Produce repeatable automated and manual evidence that the complete MVP builds, runs, and satisfies its acceptance workflows.
## Dependencies
- Feature-complete Slices 1 through 5
- Slice 7 release boundary
- Slice 8 release documentation
## In Scope
- Toolchain baseline, unit/integration/end-to-end coverage, schema compatibility, production builds, Docker validation, and release evidence
## Out of Scope
- Post-MVP testing, enterprise load certification, and formal penetration testing
## Tasks
- [ ] Install dependencies from lockfiles and document the supported toolchain.
- [ ] Establish clean frontend and backend validation commands.
- [ ] Define release-critical coverage and test layers.
- [ ] Complete frontend component, editor, binding, and Preview tests.
- [ ] Complete backend CRUD, validation, authentication, proxy, security, and persistence tests.
- [ ] Add canonical-document persistence round-trip tests.
- [ ] Add workflow-launcher, dependent-dropdown, and dashboard end-to-end scenarios.
- [ ] Validate all valid and invalid examples.
- [ ] Produce successful frontend and backend production builds.
- [ ] Verify full-stack Docker Compose startup, health, restart, and persistence.
- [ ] Run the final security regression suite.
- [ ] Record commands, test counts, artifacts, limitations, and defects.
- [ ] Update state and the final acceptance checklist.
## Acceptance Criteria
- [ ] A clean checkout can be installed, built, tested, and started from documented commands.
- [ ] All release-critical automated suites and user workflows pass.
- [ ] Docker startup, restart, health, and persistence checks pass.
- [ ] No unresolved critical or high-severity defects remain.
- [ ] Release evidence and accepted limitations are documented.
## Validation
- [ ] Frontend checks, tests, and build pass.
- [ ] Backend checks, tests, and build pass.
- [ ] Schema matrix and end-to-end suite pass.
- [ ] Docker integration and security regression checklists pass.
## Risks and Open Questions
- The first baseline could not run because dependencies were absent.
- External API tests must use controlled mocks.
- End-to-end tooling should remain minimal and maintainable.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Install locked dependencies and record the first full baseline.
- Known blockers: Final validation depends on Slices 1-5 and the Slice 7 decision.

66
SLICE7.md Normal file
View File

@ -0,0 +1,66 @@
# Slice 7: MVP Scope Decision
## Status
Not started
## Objective
Define one testable MVP release boundary, especially whether IBM Bob/watsonx integration is required for the initial release.
## Dependencies
- Product-owner decisions
- Existing requirements, architecture, and task inventory
## In Scope
- AI-in-MVP decision
- Required personas, workflows, deployment model, inclusions, exclusions, and acceptance criteria
- Reconciliation of conflicting requirement statements
## Out of Scope
- Feature implementation and detailed post-MVP roadmap planning
## Tasks
- [ ] Inventory ambiguous or conflicting MVP statements.
- [ ] Define minimum release personas and workflows.
- [ ] Decide whether AI is required, optional, or post-MVP.
- [ ] If required, define the smallest acceptable AI capability and provider boundary.
- [ ] Decide whether every modeled authentication type is release-blocking.
- [ ] Confirm component, lifecycle, persistence, export, observability, and deployment expectations.
- [ ] Define explicit non-goals and accepted limitations.
- [ ] Convert the scope into measurable release criteria.
- [ ] Update `TASKS.md`, `CODEX.md`, requirements, architecture, and dependent slices.
## Acceptance Criteria
- [ ] One authoritative MVP definition exists without contradictory release requirements.
- [ ] AI has an explicit status and, if included, a bounded acceptance test.
- [ ] Every requirement maps to a slice and validation criterion.
- [ ] Deferred features are clearly labeled post-MVP.
- [ ] Slice 6 has a definitive release checklist.
## Validation
- [ ] Requirements, architecture, tasks, and slices use consistent language.
- [ ] No open question can materially change MVP completion.
- [ ] The product owner approves the release boundary.
## Risks and Open Questions
- AI ambiguity can invalidate estimates and acceptance late in development.
- Aspirational requirements can make the MVP impractically large.
- Scope reduction must not discard required security controls.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Present conflicting statements and obtain product-owner decisions.
- Known blockers: Requires user approval and should be resolved early despite its number.

73
SLICE8.md Normal file
View File

@ -0,0 +1,73 @@
# Slice 8: Documentation
## Status
Not started
## Objective
Make documentation accurate, non-duplicative, and sufficient for development, deployment, operation, and MVP acceptance.
## Dependencies
- Slice 7 authoritative scope
- Final behavior and validation results from Slices 1 through 6
- Continuous documentation updates from every slice
## In Scope
- Documentation ownership and consolidation
- Setup, architecture, schema, security, operations, user guidance, and release evidence
- Durable Codex and slice handoff state
## Out of Scope
- Marketing content and documentation for unimplemented post-MVP features
## Tasks
- [ ] Designate `docs/` as the authoritative specification location.
- [ ] Remove, redirect, or clearly mark duplicate root documents.
- [ ] Update README prerequisites, commands, and documentation index.
- [ ] Reconcile requirements and architecture with Slice 7.
- [ ] Update schema docs and remove new deprecated `action.responseMapping` examples.
- [ ] Document active components, bindings, and visual configuration workflows.
- [ ] Document authentication, secret provisioning, and redaction.
- [ ] Document proxy policy and deployment configuration.
- [ ] Document SQLite backup, persistence, and recovery.
- [ ] Publish verified build, test, Docker, and release commands.
- [ ] Publish the final acceptance checklist and known limitations.
- [ ] Reconcile `TASKS.md`, `CODEX.md`, and all slice handoffs.
## Acceptance Criteria
- [ ] A contributor can install, run, test, and understand the project from documentation.
- [ ] An operator can configure secrets and proxy policy without reading source.
- [ ] Schema and binding examples match validated runtime behavior.
- [ ] MVP behavior and future ideas are clearly separated.
- [ ] Duplicate authoritative documents no longer create ambiguity.
- [ ] Acceptance criteria cite verified commands and outcomes.
## Validation
- [ ] Every documented command succeeds in the target environment.
- [ ] Internal links and paths are checked.
- [ ] Example JSON validates against the schema.
- [ ] Security guidance matches actual behavior.
- [ ] Task, Codex, and slice statuses agree.
## Risks and Open Questions
- Documentation will drift without continuous updates.
- Duplicate removal must wait until links and replacements are verified.
- Security documentation must not include real secrets or unsafe examples.
## Progress Log
No work recorded yet.
## Handoff
- Last completed: Slice plan created.
- Next action: Inventory document ownership after the Slice 7 decision.
- Known blockers: Final reconciliation depends on completed behavior and validation evidence.