project-loop-harness 0.2.1__tar.gz → 0.2.3__tar.gz

{project_loop_harness-0.2.1/src/project_loop_harness.egg-info → project_loop_harness-0.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: project-loop-harness
-Version: 0.2.1
+Version: 0.2.3
 Summary: Local control plane for agentic project development loops
 Author: Project Loop Harness Contributors
 License: MIT

project_loop_harness-0.2.3/agent-tasks/0092-idempotent-status-transitions.md

@@ -0,0 +1,78 @@
+# Task 0092: Idempotent Same-State Transitions (v0.2.2, F1)
+
+Source: first external-project agent dogfood feedback
+(`docs/feedback/2026-07-06-ax1-moc1-agent-feedback.md`, item F1).
+`pcl feature status F-0001 --status passing` exits 2 when the feature
+is already passing. For scripting agents a same-state request is a
+satisfied postcondition, not an input error; exit 2 forces every
+caller to pre-read state or wrap errors. No migration, no new
+dependency.
+
+## Behavior change (all four sites)
+
+Same-state transition requests become successful no-ops:
+
+- `pcl feature status <id> --status <current>` (`commands.py`
+  `set_feature_status`)
+- `pcl goal complete` / goal lifecycle same-state (`lifecycle.py`,
+  the "Goal ... is already ..." site)
+- `pcl test <verb>` when the test case is already in the requested
+  terminal state (`stories.py`, the "Test case ... is already ..."
+  site)
+- `pcl task status <id> <current>` (`tasks.py`, the "Task ... is
+  already ..." site)
+
+No-op semantics (identical across all four):
+
+- Exit code 0; JSON gains `"changed": false` plus the current status.
+- NOTHING is recorded: no status update, no inline evidence row, no
+  event append. A no-op that logs is not a no-op — repeated agent
+  retries must not inflate the audit trail.
+- Human-readable output states plainly that the entity was already in
+  the requested state (e.g. `Feature F-0001 already passing; no
+  change recorded.`).
+- Supplied `--evidence` / `--reason` text on a no-op is NOT recorded;
+  the response must make that explicit (e.g.
+  `"evidence_recorded": false`) so callers do not believe evidence
+  was attached. Attaching fresh evidence to an already-terminal state
+  (re-verification) is out of scope here and belongs to the evidence
+  entry-path design.
+
+Changed transitions additionally gain `"changed": true` (additive
+JSON field; existing fields untouched).
+
+## What must NOT change
+
+- Invalid TARGET states and disallowed transitions (e.g. rubric or
+  guard violations, unknown entities) keep their existing typed
+  errors and exit codes. Only the exact same-state case becomes a
+  no-op.
+- Evidence-backed terminal-state validation invariants are untouched
+  (a no-op changes nothing, so nothing new to validate).
+- No behavior change for transitions that DO change state, other
+  than the additive `changed` field.
+
+## Acceptance Criteria
+
+- For each of the four commands: same-state call → exit 0,
+  `changed: false`, row count of events/evidence unchanged (assert
+  counts before/after), status unchanged, and repeated invocation is
+  stable (call twice more, same result).
+- Same-state call with `--evidence "..."` → `evidence_recorded:
+  false` in JSON and no evidence row.
+- Changed-state calls still record exactly as before and now carry
+  `changed: true`.
+- Unknown entity / invalid target status still typed errors (regression
+  tests kept).
+- Docs: `docs/golden-path.md` or command docs note the idempotent
+  semantics in one short paragraph.
+- `ruff check .` passes; full `python3 -m pytest` passes; `pcl init`
+  smoke against a temp dir passes.
+
+## Do Not
+
+- Do not make disallowed transitions succeed.
+- Do not append events or evidence on no-ops.
+- Do not add a `--force` re-record path (that is evidence-path design
+  territory).
+- Do not touch schema or raw SQL outside the existing service layer.

project_loop_harness-0.2.3/agent-tasks/0093-evidence-add-command.md

@@ -0,0 +1,95 @@
+# Task 0093: `pcl evidence add` + Adhoc Bundles (v0.2.2, F2/F6)
+
+Design source: `docs/evidence-entry-paths-design.md`
+(**APPROVED 2026-07-07**, Parts 1-2 and the approval record). Where
+this spec and the design doc disagree, the design doc wins. No
+migration, no new runtime dependency; schema stays v5.
+
+## Goal
+
+Operators and agents produce reviewable artifacts outside the job
+loop (test output, screenshots, visual-check reports) and PLH has no
+honest way to accept them as evidence. Add the missing primitive.
+
+## Scope
+
+### 1. `pcl evidence add`
+
+```bash
+pcl evidence add --file work/reports/pytest-out.txt \
+  --summary "pytest run for suggestion E-0017/VS-01" \
+  --command "python3 -m pytest tests/test_context.py" --json
+```
+
+- `--file` is required and repeatable; every path must exist and be
+  readable at record time (missing/unreadable → typed error, nothing
+  recorded). `--summary` required. `--command` optional — it is the
+  CALLER'S claim of how the artifact was produced; PLH stores it
+  verbatim and never runs or verifies it (docs and help must say
+  this).
+- One file → evidence `type = 'adhoc_artifact'` (approved). Two or
+  more files → `type = 'adhoc_bundle'` (approved).
+- In both cases PLH writes a small manifest JSON under
+  `.project-loop/evidence/adhoc/` recording, per member: relative
+  path, size_bytes, sha256 — pinned AT RECORD TIME. Members are
+  referenced in place, NOT copied (approved; a `--copy` mode is a
+  possible later addition, do not add it now).
+- The evidence row's `path` points at the manifest; `command` and
+  `summary` come from the flags. One evidence row per invocation, one
+  standard event via `append_event` (SQLite + JSONL both — never a
+  side-channel writer; see agent-tasks/0089 clarification).
+- Manifest contract name: `adhoc-evidence/v0` with a
+  `contract_version` field. Deterministic member ordering (input
+  order preserved; duplicates by path → typed error).
+- JSON output returns the evidence id, type, manifest path, and the
+  member list with hashes.
+
+### 2. Strict validation integration
+
+- `pcl validate --strict` verifies for adhoc evidence rows that the
+  manifest file exists and parses; missing/corrupt manifest is an
+  ERROR (state integrity).
+- Member hash drift (file changed or deleted since recording) is a
+  WARNING, not an error (approved): drift is the working tree moving
+  on; the pinned hash remains the recorded claim. Warning text must
+  name the evidence id, member path, and which aspect drifted
+  (missing vs hash mismatch).
+
+### 3. Documentation
+
+- New section in `docs/data-model.md` or `docs/golden-path.md`:
+  the adhoc evidence flow, the claim/pointer epistemic boundary, and
+  the worked example ending in
+  `pcl verification feedback ... --evidence E-00xx`.
+- `docs/evidence-entry-paths-design.md` stays the design record; do
+  not duplicate it wholesale.
+
+## Acceptance Criteria
+
+- Single file → `adhoc_artifact`; multiple files → `adhoc_bundle`;
+  manifest carries per-member path/size/sha256; JSON output matches.
+- Determinism: same files, same flags → identical manifest content
+  except created_at/evidence id.
+- Missing file, unreadable file, duplicate path → distinct typed
+  errors, no evidence row, no event, no manifest file left behind.
+- `validate --strict`: green after add; deleting a member → WARNING
+  (still ok); editing a member → WARNING naming the hash mismatch;
+  deleting the MANIFEST → ERROR.
+- End-to-end test: `evidence add` → `verification feedback
+  --status executed --evidence <new id>` succeeds (closes the M2
+  dogfood gap).
+- Events mirrored in SQLite and JSONL; strict audit integrity stays
+  green (regression test).
+- `ruff check .` passes; full `python3 -m pytest` passes; `pcl init`
+  smoke against a temp dir passes.
+
+## Do Not
+
+- Do not copy member files or add `--copy` yet.
+- Do not execute `--command` or capture output (`--capture` is out of
+  scope by design).
+- Do not add an M:N evidence link table or any migration.
+- Do not use "verified"/"safe" language for adhoc evidence — it is a
+  recorded claim with pinned hashes.
+- Do not touch `verification feedback` flags (`--output-file` is
+  formally superseded, not implemented).

project_loop_harness-0.2.3/agent-tasks/0094-job-completion-evidence.md

@@ -0,0 +1,71 @@
+# Task 0094: Job Completion Evidence Linkage (v0.2.2, F3)
+
+Design source: `docs/evidence-entry-paths-design.md`
+(**APPROVED 2026-07-07**, Part 3). Depends on 0093 being merged (its
+adhoc evidence rows are natural inputs here, and both touch cli.py /
+validators tests). No migration; schema stays v5.
+
+## Goal
+
+In the ax1-moc1 dogfood run, `pcl jobs list --json` showed empty
+evidence for jobs whose `output_path` files existed, and there was no
+way to attach evidence when completing a job. Close both gaps using
+the EXISTING `latest_evidence_id` pointer on agent jobs.
+
+## Scope
+
+### 1. `pcl jobs complete <job-id> --evidence E-00xx`
+
+- Optional repeatable? NO — single `--evidence` flag (the
+  one-pointer model matches `latest_evidence_id`; multiple artifacts
+  are one adhoc bundle from 0093).
+- The referenced evidence row must exist → typed error otherwise,
+  nothing changed.
+- Sets `latest_evidence_id` on the job as part of the existing
+  completion flow; completion event payload gains the evidence id.
+  All existing completion semantics (summary, status transition,
+  guards) unchanged.
+
+### 2. Jobs-list evidence visibility audit (the ax1-moc1 symptom)
+
+- Reproduce first: in the ax1-moc1 run, jobs completed through the
+  normal flow showed `evidence: []`/empty in `pcl jobs list --json`
+  even though `output_path` existed and ingest had run. Find out
+  why (linkage never set? read path not surfacing it? ingest path
+  only sets it on certain flows?) and fix the actual cause — do not
+  paper over it in the list renderer.
+- After the fix: a job whose output was ingested surfaces its
+  evidence reference in `jobs read` / `jobs list --json` and
+  dashboard-data.
+
+### 3. Documentation
+
+- `docs/golden-path.md` / agent adapter docs: one short paragraph —
+  complete a job with `--evidence` when the artifact is already
+  recorded (0093 flow), otherwise ingest output as before.
+
+## Acceptance Criteria
+
+- `jobs complete --evidence E-00xx` sets `latest_evidence_id`,
+  appends the completion event with the evidence id, and the linkage
+  appears in `jobs read --json`, `jobs list --json`, and
+  dashboard-data.
+- Unknown evidence id → typed error; job stays incomplete and
+  unchanged.
+- Root-cause test for the visibility bug: a test that reproduces the
+  original empty-evidence symptom path and asserts it is fixed
+  (write the test against the actual discovered cause, and explain
+  the cause in the task report).
+- Existing completion without `--evidence` behaves exactly as
+  before.
+- `ruff check .` passes; full `python3 -m pytest` passes; `pcl init`
+  smoke against a temp dir passes; strict validate/audit integrity
+  regression stays green.
+
+## Do Not
+
+- Do not add repeatable `--evidence` or an M:N link table.
+- Do not auto-create evidence from `output_path` without ingest —
+  linkage requires a real evidence row.
+- Do not change ingest contracts (`agent-output/v1`) or job state
+  machine semantics.

project_loop_harness-0.2.3/agent-tasks/0095-supporting-evidence-health.md

@@ -0,0 +1,156 @@
+# Task 0095: Supporting Evidence Health in Verification Stats (v0.2.3, P0)
+
+Origin: GPT-5.5-pro v0.2.2 review agenda, blind spot B ("feedback stats
+do not look at the health of supporting evidence"). No migration, no
+new runtime dependency; schema stays v5.
+
+## Goal
+
+`verification_feedback` rows can reference a `supporting_evidence_id`.
+Since v0.2.2 that evidence is often an `adhoc_artifact` / `adhoc_bundle`
+whose members are referenced (not copied) and hash-pinned. Stats can
+therefore show a healthy `executed_pass_rate` while the artifacts
+backing those feedbacks have since gone missing or drifted.
+
+Add a **derived, read-only health axis** to `pcl verification stats
+--json` that reports whether the supporting evidence behind executed
+feedback is still reviewable today. Do NOT change any existing metric
+and do NOT rewrite any feedback row: PLH records facts append-only;
+health is a separate, current-time observation about reviewability.
+
+## Vocabulary (binding)
+
+- Health values: `ok` | `warning` | `error` | `unknown`.
+- Health describes "current reviewability of the referenced
+  artifacts". It never asserts the original claim was true or false.
+- Forbidden in new output, help text, and docs for this feature:
+  "verified", "proven", "guaranteed", "invalid(ated)". A drifted
+  artifact does not invalidate a past feedback; it makes it harder to
+  review now.
+
+## Scope
+
+### 1. Shared adhoc health assessment
+
+Extract the adhoc manifest/member checks that already exist in
+`src/pcl/validators.py` (`_validate_adhoc_evidence_manifests` /
+`_validate_adhoc_members`) into a shared, structured assessment
+function in `src/pcl/evidence.py`, e.g.:
+
+```python
+def assess_adhoc_evidence(paths, *, evidence_id, evidence_type, manifest_path_value) -> dict
+# -> {"health": "ok"|"warning"|"error", "findings": [{"code": ..., "path": ...?, "detail": ...?}]}
+```
+
+Structured finding codes (at minimum): `manifest_not_local`,
+`manifest_missing`, `manifest_not_file`, `manifest_corrupt`,
+`contract_version_unsupported`, `evidence_id_mismatch`,
+`evidence_type_mismatch`, `members_invalid`, `member_entry_invalid`,
+`member_missing`, `member_hash_mismatch`.
+
+Severity mapping mirrors today's validator semantics exactly:
+structural manifest problems are `error`; member drift (missing file
+or hash mismatch) is `warning`; everything intact is `ok`.
+
+`validators.py` must consume this shared function so drift semantics
+have a single source. Protective invariant, scoped: **the rendered
+`pcl validate` / `pcl validate --strict` messages for the existing
+test fixtures must remain unchanged — all existing validator tests
+pass unmodified.** If message-identical rendering from structured
+findings proves impossible for some edge case, stop and report
+instead of changing a message.
+
+The assessment must tolerate (ignore) unknown extra keys on manifest
+members — task 0096 will add fields such as `path_scope` later.
+
+### 2. `supporting_evidence_health` in stats
+
+In `verification_feedback_stats` (`src/pcl/verification_feedback.py`),
+assess every **distinct** `supporting_evidence_id` referenced by
+feedback rows already loaded for stats (all statuses, not just
+executed — a `skipped` feedback can also carry evidence):
+
+- Evidence row absent in `evidence` table → `error` with finding
+  `evidence_row_missing`. (Normally impossible — record-time checks
+  existence — but deletion/corruption must surface, not crash.)
+- Evidence row present, `type` in (`adhoc_artifact`, `adhoc_bundle`)
+  → result of the shared assessment.
+- Evidence row present, any other type (`context_receipt`, ingested
+  agent output, test evidence, ...) → `unknown` with finding
+  `health_not_assessed_for_type`. v0 assesses adhoc only; do not
+  invent checks for other types.
+
+Each distinct evidence id is assessed (and its member files hashed)
+at most once per stats invocation.
+
+New sibling section in the returned `stats` object (additive only —
+no existing key changes, no metric formula changes):
+
+```json
+"supporting_evidence_health": {
+  "assessed_evidence_count": 2,
+  "feedback_events_with_supporting_evidence_count": 3,
+  "health_counts": {"ok": 1, "warning": 0, "error": 0, "unknown": 1},
+  "by_evidence_id": {
+    "E-0018": {"health": "ok", "findings": []},
+    "E-0017": {"health": "unknown",
+               "findings": [{"code": "health_not_assessed_for_type",
+                              "detail": "context_receipt"}]}
+  }
+}
+```
+
+Additionally, each entry in the existing
+`latest_feedback_by_suggestion` map gains a
+`supporting_evidence_health` key: the health string when that
+feedback row has a `supporting_evidence_id`, else `null`.
+
+### 3. Read surfaces and docs
+
+- `pcl verification stats --json` carries the new section (it already
+  prints the stats dict; no new flag).
+- Docs: extend `docs/verification-feedback.md` with a
+  "Supporting evidence health" section covering the four health
+  values, the adhoc-only v0 scope, and the binding vocabulary rule
+  (health ≠ truth; feedback rows are never rewritten).
+
+## Non-goals
+
+- No change to `pcl validate` behavior or output (refactor only).
+- No dashboard/report rendering of health (v0.2.4 UX round).
+- No health for non-adhoc evidence types beyond `unknown`.
+- No caching of hash checks across invocations.
+- No new events, no DB writes: stats stays a pure read. Protective
+  invariant, scoped: **a `pcl verification stats` invocation must not
+  append to `events.jsonl` nor change any table row** (assert in a
+  test via row counts / file size before and after).
+
+## Tests
+
+1. Feedback with adhoc supporting evidence, members intact → `ok`;
+   health appears in `by_evidence_id` and in
+   `latest_feedback_by_suggestion`.
+2. Overwrite one member file after recording → `warning` with
+   `member_hash_mismatch`; delete a member → `warning` with
+   `member_missing`. Existing metrics (`executed_pass_rate` etc.)
+   unchanged by drift.
+3. Delete the manifest file → `error` with `manifest_missing`.
+4. Supporting evidence of a non-adhoc type → `unknown`.
+5. Feedback without `supporting_evidence_id` → excluded from
+   `health_counts`; `supporting_evidence_health: null` in
+   `latest_feedback_by_suggestion`.
+6. Same evidence id referenced by two feedback rows → assessed once,
+   counted once in `health_counts`.
+7. Stats invocation performs no writes (events.jsonl byte size and
+   evidence/feedback row counts identical before/after).
+8. All existing validator and stats tests pass unmodified.
+
+## Definition of done
+
+- Implementation + tests green (`python3 -m pytest`).
+- Live smoke against this repo's own `.project-loop` (it already has
+  VF-0001/VF-0002 and E-0017/E-0018 from dogfood): stats shows
+  `ok` for E-0018 (adhoc) and `unknown` for E-0017 (context_receipt);
+  then temporarily drift a member copy in a scratch project (not the
+  live DB) to show `warning`.
+- Docs updated. Evidence paths for all claims.

project_loop_harness-0.2.3/agent-tasks/0096-evidence-add-path-guards.md

@@ -0,0 +1,185 @@
+# Task 0096: Evidence Add Path Guards — Scope + Sensitive Shape (v0.2.3, P0)
+
+Origin: GPT-5.5-pro v0.2.2 review agenda, blind spots C (project
+boundary) and D (secret-shaped files), merged into one task because
+both are record-time guards on the same code path
+(`src/pcl/evidence.py::_adhoc_members`). No migration, no new runtime
+dependency; schema stays v5. Runs AFTER 0095 is merged (both touch
+`evidence.py` / `validators.py`).
+
+## Goal
+
+`pcl evidence add` accepts any existing local file. Two gaps:
+
+1. A file outside the project root is silently recorded with a
+   `../...` relative member path — invisible in the manifest, likely
+   unreproducible on another machine.
+2. An agent can pass `.env`, a private key, or a credentials file and
+   PLH records it without any friction.
+
+Add explicit accounting for the project boundary and a name-shaped
+sensitive-path guard. PLH is NOT a content scanner and must not
+become one: both guards look at paths only, never file contents, and
+docs must say so.
+
+## Part A: path scope accounting
+
+### Member field
+
+Every manifest member (and the members echoed in the
+`adhoc_evidence_recorded` event payload and the CLI JSON result)
+gains:
+
+```json
+"path_scope": "in_project" | "outside_project"
+```
+
+Determination: after the existing `resolve()`, the member is
+`in_project` iff `resolved.relative_to(paths.root.resolve())`
+succeeds — the same boundary `_relative_path` already uses.
+
+### Behavior
+
+- Default: `outside_project` members are recorded, with a warning.
+  - Text mode: warning line on stderr.
+  - JSON mode: additive top-level `"warnings": [...]` array in the
+    result (present only when non-empty), one entry per
+    outside-project member, e.g.
+    `"evidence member outside project root: ../tmp/report.txt"`.
+- `pcl.yaml` opt-in hard boundary:
+
+  ```yaml
+  evidence:
+    allow_outside_root: false
+  ```
+
+  When set to `false`, any outside-project member → typed error
+  `evidence_add_outside_root` (exit 2). Absent key or `true` =
+  default warning behavior. Read the key with the same tolerant
+  pcl.yaml reading approach used elsewhere (see
+  `_configured_yaml_list` in `src/pcl/code_context/scan.py` for the
+  house style; a scalar sibling helper is fine).
+
+## Part B: sensitive-shaped path guard
+
+### Patterns
+
+- Reuse `DEFAULT_SENSITIVE_EXCLUDES` and `_path_pattern_matches` from
+  `pcl.code_context` (import them; do NOT copy the pattern list —
+  one source of truth).
+- Optional additional patterns from `pcl.yaml`:
+
+  ```yaml
+  evidence:
+    sensitive_exclude:
+      - "*.sqlite3"
+  ```
+
+- `code_index.sensitive_include_override` does NOT apply here — it is
+  index-scoped. There is no override list for evidence; the override
+  is the explicit CLI flag below.
+
+### Matching
+
+For each member, match patterns against:
+
+1. the recorded member path (the project-relative / `../`-relative
+   form that goes into the manifest), and
+2. the file's basename (so `/Users/x/.env` recorded as
+   `../../.env` still matches `.env`; directory patterns like
+   `.aws/` cannot anchor across `../` prefixes otherwise).
+
+### Behavior
+
+- If any member matches and `--allow-sensitive-evidence` was NOT
+  passed → typed error `evidence_add_sensitive_path` (exit 2) listing
+  the matched paths and patterns in `details`, and telling the caller
+  about `--allow-sensitive-evidence`. This is the default in ALL
+  modes — the CLI is non-interactive; there is no prompt.
+- With `--allow-sensitive-evidence`:
+  - members are recorded; each matched member gains
+    `"sensitive_pattern": "<pattern>"` in the manifest/event/result;
+  - the manifest gains top-level
+    `"sensitive_path_warning_count": <int>` (count of matched
+    members); the event payload carries the same count;
+  - a warning is still emitted (stderr in text mode, `warnings` array
+    entry in JSON mode).
+- Help text and docs must state: this is a filename-shape check only;
+  PLH does not scan file contents and recording with the flag is the
+  caller's explicit decision.
+
+## Guard ordering and atomicity
+
+Both guards run inside the pre-DB stage (`_adhoc_members`), after the
+existing exists/readable/duplicate checks, before any ID allocation,
+manifest write, DB insert, or event append. Protective invariant,
+scoped, same as 0093: **on any typed error from `pcl evidence add`,
+zero traces — no evidence row, no JSONL event, no manifest file, no
+consumed evidence ID, and the `evidence/adhoc/` directory file count
+is unchanged** (assert in tests).
+
+Evaluation order when multiple guards fire: report the sensitive
+error first (it is the safety guard), then outside-root. A single
+typed error is enough; do not build a multi-error report.
+
+## Validators (`src/pcl/validators.py`)
+
+- New optional member fields `path_scope`, `sensitive_pattern` and
+  manifest field `sensitive_path_warning_count` are accepted:
+  - absent → fine (pre-0096 manifests stay valid, no new errors);
+  - present with an invalid value (unknown scope string,
+    non-string pattern, negative/non-int count) → error.
+- New warning, applies to old and new manifests alike since it is
+  derivable from the path itself: a member path starting with `../`
+  → warning `Adhoc evidence <id> member <path> is outside the project
+  root.` This complements, not replaces, the existing drift warnings.
+- The 0095 shared assessment function gains a corresponding finding
+  code `member_outside_project_root` at `warning` severity, so stats
+  health reflects the same fact. Existing fixtures without outside
+  members must produce byte-identical validate output.
+
+## Non-goals
+
+- No content scanning, no entropy heuristics, no secret detection.
+- No change to code index sensitive behavior or context receipts.
+- No dashboard/report highlighting (v0.2.4 UX round).
+- No copy/snapshot mode (task 0097 designs it).
+- No interactive confirmation prompts.
+
+## Tests
+
+1. In-project file → `path_scope: "in_project"`, no warnings key,
+   output otherwise identical to v0.2.2 shape plus the new field.
+2. File under a temp dir outside root → recorded, member has
+   `outside_project`, JSON result has `warnings`, manifest path is
+   `../...`.
+3. Same with `evidence.allow_outside_root: false` → typed
+   `evidence_add_outside_root`, exit 2, zero traces.
+4. `.env` inside project without flag → typed
+   `evidence_add_sensitive_path`, exit 2, zero traces.
+5. `.env` with `--allow-sensitive-evidence` → recorded;
+   `sensitive_pattern` on the member;
+   `sensitive_path_warning_count: 1`; warning emitted.
+6. Outside-project `/tmp/.../credentials-prod.json` without flag →
+   blocked via basename matching.
+7. `evidence.sensitive_exclude` additional pattern matches → blocked
+   without flag.
+8. Bundle mixing one sensitive + one clean member without flag →
+   blocked, zero traces (no partial manifest).
+9. Sensitive + outside-root simultaneously, no flag → the sensitive
+   error is the one reported.
+10. Validators: pre-0096 manifest (no new fields) still valid;
+    manifest with `../` member path → outside-root warning; invalid
+    `path_scope` value → error.
+11. Strict validate output for existing fixtures unchanged.
+
+## Definition of done
+
+- Implementation + tests green (`python3 -m pytest`).
+- Live smoke in a scratch project (`pcl init /tmp/pcl-demo` style):
+  demonstrate cases 2, 4, 5 with real files and show the manifest
+  JSON. Do NOT add sensitive-named files to the live PLH repo DB.
+- `docs/evidence-entry-paths-design.md` gains a short "Path guards
+  (0096)" section documenting scope accounting, the guard, the
+  config keys, and the not-a-content-scanner boundary.
+- Evidence paths for all claims.

project_loop_harness-0.2.3/agent-tasks/0097-evidence-durability-design.md

@@ -0,0 +1,54 @@
+# Task 0097: Evidence Durability Modes — Design Only (v0.2.3, P1)
+
+Origin: GPT-5.5-pro v0.2.2 review agenda, blind spot A ("hash-pin is
+not durability"). **This task produces a design document only — no
+code, no schema change, no CLI change.** Authored by the
+orchestrator (not dispatched to an implementation worker) because it
+is a judgment/trade-off document requiring approval, not a build.
+
+## Problem
+
+v0.2.2 adhoc evidence records member path + size + sha256 but never
+copies the file. This is honest ("existed with this content at record
+time") but weak for later review: cleanup deletes
+`work/reports/pytest-out.txt`, CI artifacts expire, screenshots live
+outside the repo, overwritten files leave only a drift warning.
+
+A naive `--copy` does not fix this either, because
+`.project-loop/evidence/` is **gitignored** (`.gitignore:20`): a copy
+survives local cleanup but still does not travel to another machine
+or reviewer. Durability design is inseparable from the git/versioning
+boundary of `.project-loop`, so the boundary question must be settled
+before any implementation.
+
+## Deliverable
+
+`docs/evidence-durability-design.md` covering at minimum:
+
+1. Modes: `reference` (today, stays default) vs explicit `--copy`
+   (member files copied under `.project-loop/evidence/adhoc-files/`)
+   vs a possible `--snapshot`/export-bundle variant; what each does
+   and does not promise.
+2. Manifest accounting: `storage_mode: reference | copied` per
+   member or per manifest; interaction with drift detection (a copy
+   can also drift or be deleted).
+3. The gitignore boundary problem: options (keep evidence local-only;
+   carve out a committed evidence subdirectory; an explicit
+   `pcl evidence export` bundle for hand-off) with a recommendation.
+4. Interaction with 0096 guards: copying must never weaken them —
+   sensitive-shaped members and outside-root members and copy mode
+   compose (e.g. copying an outside-root file pulls it inside the
+   boundary: is that a feature or a loophole? decide and say why).
+5. Size discipline: soft cap for copied members, `large_evidence_member`
+   warning, relation to strict-validate hash cost (review blind spot
+   F stays backlog; the design should not preclude it).
+6. Truthfulness boundary: PLH never claims copied content is correct,
+   only that it was copied from the named path at record time.
+7. Decision points listed explicitly for approval; no default-copy —
+   copying stays opt-in per invocation.
+
+## Definition of done
+
+- Design doc committed to `main`, marked as awaiting approval.
+- Open decisions presented for approval before any implementation
+  task is cut (implementation would be a v0.2.4+ task).