docs: align P2-P6 planning artifacts with the P1.1 registry contract
This commit is contained in:
@@ -19,7 +19,7 @@
|
||||
P2 is complete only when all of the following are true:
|
||||
|
||||
1. The only public host interface is the installed native `thothctl` binary. Docker/Compose is required, but host Python, Node, Pi, `tht`, and a running Fastify backend are not.
|
||||
2. Every command consumes an already-active, validated registry snapshot and binds the exact workspace ID, 40-hex commit, descriptor blob/digest, installation bindings, runtime roots, and selected internal semantic contract before mutation.
|
||||
2. Every command consumes an already-active, validated P1.1 registry snapshot and binds the exact workspace ID, 40-hex commit, catalog blob (`thoth-workspaces.yaml`), descriptor blob/digest, installation bindings, runtime roots, and selected internal semantic contract before mutation. A docs-only or content-only commit is still a distinct revision even when the descriptor blob is unchanged, because the commit is authoritative.
|
||||
3. Operator and session configuration use the same `resolveRuntimeBindings` and `renderRuntimeConfig` implementation. P2 uses one deterministic same-revision config-source path so current schema-v1 DWH/Evidence resume works; P3 later introduces cross-revision canonical effective identity and explicit migrations.
|
||||
4. DWH introspection+LSH, FK suggestion/check, schema indexing, and HTTP Evidence preprocessing invoke the existing harness engine through fixed argv and pristine JSON machine interfaces. No second preprocessing engine is added.
|
||||
5. A full run with new FK candidates stops before schema/Evidence writes. Continuation requires a reviewer-supplied annotations file and an explicit acknowledgement of the exact candidate digest; `schema check` alone is not treated as human approval.
|
||||
@@ -141,7 +141,7 @@ interface WorkspaceOperationResult {
|
||||
- Lock order is always P2 workspace writer lock → existing harness stage lock. Harness code never acquires the P2 lock, preventing inversion/deadlock.
|
||||
- Every directory component is opened/validated without following symlinks. State files are `0600`, written to an exclusive sibling, fsynced, renamed, and parent-fsynced. Hardlink count must be one.
|
||||
- The deterministic config path fixes P2 same-revision `config_source` identity. Its manifest binds workspace, revision, descriptor blob, config SHA-256, file identity, and the current existing harness ownership binding. Same path + different bytes returns `effective_config_mismatch`; P3 introduces semantic cross-revision equivalence.
|
||||
- Job state binds operation, revision, descriptor blob, config digest, non-secret binding identity, completed stage records, child run IDs, candidate/review digests, and terminal status. Resume revalidates all fields and reconciles a child publication that completed immediately before an outer-state crash.
|
||||
- Job state binds operation, revision, catalog blob, descriptor blob, config digest, non-secret binding identity, completed stage records, child run IDs, candidate/review digests, and terminal status. Resume revalidates all fields and reconciles a child publication that completed immediately before an outer-state crash.
|
||||
- Before any schema/Evidence mutation, enumerate resumable session manifests for the workspace. A different pinned revision returns `preprocessing_conflict`; no write begins. This is the explicit P2 bridge until P3 revision isolation.
|
||||
|
||||
## One-shot service security contract
|
||||
@@ -473,7 +473,7 @@ The public command is:
|
||||
```
|
||||
|
||||
- [ ] **Step 1: Write RED acceptance-runner tests** for ownership-first state, unique run/project/container/image names, exact cleanup, `--keep`, injected failure, signal cleanup, report bounds, and no automatic retry.
|
||||
- [ ] **Step 2: Build a clean owned topology** under `.artifacts/p2-integration/p2-<run-id>/`: local bare Git + author clone, active P1 snapshot, installation descriptor/env, fixture-only secrets, controlled REST DWH, controlled HTTP Evidence, real compatible Qdrant, deterministic Ollama-compatible embedding fixture, selected core image, and no backend/Pi/frontend.
|
||||
- [ ] **Step 2: Build a clean owned topology** under `.artifacts/p2-integration/p2-<run-id>/`: local bare Git + author clone, active P1.1 snapshot (root catalog + `<id>/workspace.yaml` + `<id>/evidence`), installation descriptor/env, fixture-only secrets, controlled REST DWH, controlled HTTP Evidence, real compatible Qdrant, deterministic Ollama-compatible embedding fixture, selected core image, and no backend/Pi/frontend.
|
||||
- [ ] **Step 3: Pre-provision the exact compatible Qdrant collection** outside the product operation and record that setup as a P4-deferred fixture step.
|
||||
- [ ] **Step 4: Exercise only built `thothctl` product commands** and assert:
|
||||
1. exact inspect revision/config identity;
|
||||
|
||||
@@ -44,7 +44,9 @@ Every operation binds these values before doing work:
|
||||
|
||||
- workspace ID;
|
||||
- exact 40-hex active Git commit;
|
||||
- exact canonical descriptor snapshot;
|
||||
- catalog entry (`thoth-workspaces.yaml`) and exact canonical descriptor snapshot (the catalog blob
|
||||
and descriptor blob at that same commit; a docs-only or content-only commit is still a distinct
|
||||
revision even when the descriptor blob is unchanged, because the commit is authoritative);
|
||||
- installation-local bindings resolved under configured secret roots;
|
||||
- runtime roots beneath `/data/sessions/<workspace-id>`;
|
||||
- internal Qdrant/Ollama contract;
|
||||
@@ -169,7 +171,7 @@ rollback of lost vector data.
|
||||
The canonical path is fixed, not descriptor-configurable:
|
||||
|
||||
```text
|
||||
workspace-content/<workspace-id>/schema/annotations.yaml
|
||||
<workspace-id>/schema/annotations.yaml
|
||||
```
|
||||
|
||||
The registry validates that the object is a regular Git blob at the same commit as the descriptor.
|
||||
@@ -206,7 +208,7 @@ accepted blob and compatible reusable DWH binding; otherwise it starts a new run
|
||||
## 8. P6 — commit-addressed Evidence materialization
|
||||
|
||||
For filesystem Evidence, the registry materializes exactly
|
||||
`workspace-content/<id>/evidence` from the pinned commit into an immutable revision content root.
|
||||
`<id>/evidence` from the pinned commit into an immutable revision content root.
|
||||
It does not consume the mobile registry checkout and does not resolve against author files.
|
||||
|
||||
Materialization uses fixed Git plumbing to enumerate object type, mode, path, object ID, and bytes.
|
||||
|
||||
Reference in New Issue
Block a user