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

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

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

project_loop_harness-0.2.2/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.2/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.2/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.1 → project_loop_harness-0.2.2}/docs/agent-adapter-contract.md

@@ -78,6 +78,12 @@ The expected output path is deterministic:
 
 The ingest path must be the project-scoped `.project-loop/evidence/agent-runs/<job_id>/output.md`. Files from another directory, even if they contain an `agent-runs/<job_id>` segment, are rejected. Ingest is also a guarded state transition: cancelled or failed jobs cannot be revived by late output, and inactive workflow runs cannot accept new agent output.
 
+If a job artifact has already been recorded with `pcl evidence add`, complete
+the job with `pcl jobs complete <job-id> --evidence E-00xx` to link that
+existing evidence row. Otherwise, keep using `pcl ingest-agent-run` for raw
+agent output so PLH validates `agent-output/v1`, creates the evidence row, and
+marks the job passed in one guarded transition.
+
 After ingest, `pcl jobs read J-0001 --json` and `pcl jobs list --json` expose the derived evidence linkage:
 
 ```json
@@ -88,7 +94,7 @@ After ingest, `pcl jobs read J-0001 --json` and `pcl jobs list --json` expose th
 }
 ```
 
-The linkage is derived from `agent_output_ingested` events and `evidence` rows, not from a mutable `agent_jobs.evidence_id` column. Repeated ingests can therefore preserve multiple evidence ids while the latest evidence remains easy to find from job surfaces and the dashboard.
+The linkage is derived from `agent_output_ingested` events, evidence-bearing `agent_job_completed` events, and `evidence` rows, not from a mutable `agent_jobs.evidence_id` column. Repeated ingests can therefore preserve multiple evidence ids while the latest evidence remains easy to find from job surfaces and the dashboard.
 
 ## Minimal Output File
 

{project_loop_harness-0.2.1 → project_loop_harness-0.2.2}/docs/data-model.md

@@ -171,6 +171,42 @@ under `.project-loop/evidence/context-receipts/` and registers it through the
 existing `evidence` table with type `context_receipt`, plus an append-only
 event.
 
+## Adhoc Evidence Manifests
+
+`pcl evidence add` records existing local files that were produced outside the
+agent-job ingest path. One `--file` creates evidence type `adhoc_artifact`; two
+or more `--file` flags create `adhoc_bundle`.
+
+The command writes an `adhoc-evidence/v0` manifest under
+`.project-loop/evidence/adhoc/` and stores one `evidence` row whose `path`
+points at that manifest. Manifest members are referenced in place and pinned at
+record time with only:
+
+- relative `path`;
+- `size_bytes`;
+- `sha256`.
+
+Member files are not copied and their contents are never embedded in the
+manifest. The optional `--command` value is the caller's claim about how the
+artifact was produced. PLH stores it verbatim on the evidence row; it does not
+run the command or verify that the command produced the files.
+
+Strict validation treats a missing or corrupt adhoc manifest as a state
+integrity error. If a referenced member file is later deleted or edited, strict
+validation reports a warning naming the evidence id, member path, and drift kind
+while keeping the recorded hash as the pinned claim.
+
+Worked example:
+
+```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
+pcl verification feedback --suggestion E-0017/VS-01 --status executed --result passed --evidence E-00xx
+```
+
 ## Verification Feedback
 
 Schema version 5 adds `verification_feedback`, an append-only event table for

{project_loop_harness-0.2.1 → project_loop_harness-0.2.2}/docs/distribution.md

@@ -134,7 +134,7 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: "3.11"
-      - uses: owner/project-loop-harness/.github/actions/project-loop-validate@v0.2.1
+      - uses: owner/project-loop-harness/.github/actions/project-loop-validate@v0.2.2
         with:
           root: "."
           strict: "true"

project_loop_harness-0.2.2/docs/evidence-entry-paths-design.md

@@ -0,0 +1,119 @@
+# v0.2.2 Design: Evidence Entry Paths
+
+Status: **APPROVED 2026-07-07 (human approval).** Decisions: (1) two
+evidence types `adhoc_artifact` / `adhoc_bundle`; (2) bundle-member
+hash drift is a WARNING in `pcl validate --strict`, not an error;
+(3) the `verification feedback --output-file` idea is formally
+superseded by `pcl evidence add`. No migration; everything stays on
+schema v5. Implementation: task 0093 then 0094.
+
+Sources: v0.2.0 plan M2 dogfood finding (ad-hoc executed feedback has
+no evidence path) and ax1-moc1 external-project agent feedback items
+F2 (single-string `--evidence`), F3 (job completion evidence), F6
+(evidence bundle for screenshot + viewport + visual-check). These are
+four surfaces of ONE gap: **operators and agents produce reviewable
+artifacts outside the job loop, and PLH has no honest way to accept
+them as evidence.**
+
+## Design principles (unchanged)
+
+- Evidence rows are claims with pointers: PLH records that an
+  artifact existed with a given hash at record time. It never claims
+  the artifact is correct or that PLH observed its production.
+- CLI-only mutation; every insert goes through the service layer and
+  appends a standard event (SQLite + JSONL via `append_event`).
+- No fabrication: PLH never generates artifact content on the
+  caller's behalf.
+
+## Part 1: `pcl evidence add` (the missing primitive)
+
+```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
+```
+
+- Requires at least one existing, readable `--file`; records path,
+  size, and sha256 AT RECORD TIME into a small manifest artifact
+  under `.project-loop/evidence/adhoc/`, creates one evidence row
+  pointing at that manifest, and appends one event.
+- Evidence `type` is `adhoc_artifact` — the epistemic marker that
+  this entered outside the job/workflow loop. Reports, dashboards,
+  and strict validation treat it as normal evidence; the type makes
+  provenance visible, not second-class.
+- `--command` is the CALLER'S statement of how the artifact was
+  produced. PLH stores it verbatim as a claim; it does not run or
+  verify it (same discipline as `verification_feedback.executed`).
+- This closes the M2 dogfood gap directly:
+  `pcl evidence add --file out.txt ...` → `E-00xx` →
+  `pcl verification feedback --suggestion 'E-0017/VS-01'
+  --status executed --result passed --evidence E-00xx`.
+- The earlier `--output-file` idea on `verification feedback` is
+  SUPERSEDED by this: one general primitive instead of a per-command
+  attachment flag.
+
+## Part 2: bundles — multiple files, ONE evidence row (F2 + F6)
+
+`--file` is repeatable. Two or more files produce a single evidence
+row of type `adhoc_bundle` whose manifest lists every member with
+path, size, and sha256:
+
+```bash
+pcl evidence add \
+  --file work/reports/rendered-desktop.png \
+  --file work/reports/rendered-mobile.png \
+  --file work/reports/visual-check.json \
+  --summary "visual QA bundle for TC-0002"
+```
+
+- Members are referenced in place and pinned by hash — NOT copied.
+  If a member later changes on disk, the manifest hash makes the
+  drift detectable (`pcl validate --strict` may warn; blocking is a
+  later decision). A `--copy` durability mode can come later if
+  dogfood demands it.
+- This resolves F2 WITHOUT a schema change: `test_cases.evidence_id`
+  and `defects.evidence_id` stay single-column. Instead of repeatable
+  `--evidence` flags and an M:N link table (migration 006), the
+  answer is "make one bundle, link its one ID". An M:N table is
+  reconsidered only if dogfood shows bundles insufficient.
+
+## Part 3: job completion evidence (F3)
+
+- `pcl jobs complete <job-id> --evidence E-00xx` sets the job's
+  existing `latest_evidence_id` pointer (no schema change) so
+  `pcl jobs list --json` stops showing empty evidence for jobs whose
+  outputs exist.
+- Independently: when a job output file exists at `output_path` and
+  was ingested, the ingest path already creates evidence — audit why
+  `jobs list --json` showed empty evidence in the ax1-moc1 run and
+  fix the linkage/read path as part of this work.
+
+## Explicitly out of scope
+
+- Auto-execution or output capture by PLH (`--capture -- <cmd>`):
+  recording is manual; PLH does not run the caller's commands.
+- M:N evidence link tables (migration) — bundles first.
+- Re-recording evidence onto already-terminal test states (F1's
+  no-op rule stands; re-verification flow is a later design).
+- Content inspection/validation of member files beyond hashing.
+
+## Sequencing (proposed)
+
+1. **0093**: `pcl evidence add` + bundle manifest + adhoc types +
+   strict-validate integration (manifest members exist; hash drift
+   warning).
+2. **0094**: `pcl jobs complete --evidence` + the jobs-list evidence
+   visibility audit/fix.
+
+Both are additive CLI + artifact work on schema v5.
+
+## Approval record (2026-07-07)
+
+1. Two evidence types confirmed: `adhoc_artifact` (single file) /
+   `adhoc_bundle` (multiple files) — cheap to read in lists.
+2. Bundle-member hash drift in `--strict` is a WARNING. Rationale:
+   drift is a fact about the working tree moving on, not a state
+   integrity violation; the pinned hash in the manifest remains the
+   recorded claim.
+3. `verification feedback --output-file` is superseded by
+   `pcl evidence add` and will not be implemented.

project_loop_harness-0.2.2/docs/feedback/2026-07-06-ax1-moc1-agent-feedback.md

@@ -0,0 +1,55 @@
+# Dogfood Feedback: ax1-moc1 (external project, agent operator)
+
+Source: cockpit task `ae7cd335` (codex / gpt-5.5 xhigh, YOLO mode),
+project `~/Dev/ax1-moc1`, 2026-07-06. The agent implemented a
+responsive LP from 10 reference comps end-to-end under PLH
+(`project-control-loop` skill + pcl 0.2.x), completed in ~21 minutes
+with TC-0001..3 passing, F-0001 passing, US-0001 approved, J-0001..3
+passed, `pcl validate --strict` green, and stopped correctly at the
+human verification gate. Feedback below was then given by the agent
+on request. This is the first recorded end-to-end PLH run by a
+non-PLH-developer operator on a non-PLH project.
+
+## What worked (agent's words, condensed)
+
+- `pcl next` was excellent: it surfaced the next job, the pending
+  human verification, and `requires_human: true`, which prevented
+  the agent from self-approving.
+- `pcl test pass --evidence` drew the "implementation is done" line
+  well; binding rendered screenshots + visual-check JSON as evidence
+  fits web/design work.
+- Keeping dashboard HTML out of machine state was validated in
+  practice — CLI/JSON/reports sufficed.
+- The validate/render ritual felt like healthy hygiene, not busywork.
+
+## Friction points (verbatim intent, each mapped to a candidate task)
+
+| # | Feedback | Candidate response | Size |
+|---|---|---|---|
+| F1 | `pcl feature status F-0001 --status passing` exits 2 on "already passing" — hostile to agents; idempotent transitions should exit 0 + `changed: false` | Idempotent same-state lifecycle transitions across feature/test/story/task/goal commands (no state-change event on no-op) | S |
+| F2 | `--evidence` is a single string; multiple artifacts had to be `;`-joined | Repeatable `--evidence` (and/or JSON array) on evidence-accepting commands | S |
+| F3 | `jobs list --json` shows empty evidence despite `output_path`; wanted `pcl jobs complete --evidence` | Evidence linkage for job completion | S–M |
+| F4 | `feature_coverage` still queues mapper/story_writer/test_designer jobs when stories/tests already exist; agent had to write "already satisfied" reports to close them | Existing-coverage detection → mark such jobs satisfied/no-op | M |
+| F5 | At the human gate, `pcl next` should also say "agent stops HERE" and provide ready-to-send approval-request text for the user | Human-gate handoff text in `pcl next` (Japanese-first; Milestone 13 adjacency) | M |
+| F6 | Wants an evidence bundle type for screenshot + viewport + visual-check report | Evidence bundle design (fold into F2/F3 design) | M |
+| F7 | **Top ask**: a `pcl finish`-style closeout command — check test/job/story states, validate, render, generate the run report, and summarize remaining human gates in one step; "closing out PCL correctly" carried more cognitive load than the implementation itself | Closeout/finish command design (builds on checkpoint 0059 concepts) | M–L |
+
+## Cross-links to open design questions
+
+- F2/F3/F6 intersect the open `--output-file` question (ad-hoc
+  executed-feedback evidence path from the v0.2.0 plan's M2 dogfood
+  findings): all four are the same underlying gap — evidence entry
+  ergonomics for operators outside the job loop. They should be
+  designed together, not piecemeal.
+- F5 feeds the Judgment pillar (Milestone 13 human decision UI) and
+  the standing wish that escalations reach humans in readable
+  Japanese.
+- F1 is a pure agent-ergonomics fix with no contract risk and is the
+  cheapest credibility win.
+
+## Explicitly NOT conceded
+
+The agent suggested nothing that weakens the epistemic boundaries:
+the human verification gate itself was praised, not contested. No
+item above requires auto-approval, auto-execution, or go/no-go
+verdicts, and none touches the semantic promotion gate.

{project_loop_harness-0.2.1 → project_loop_harness-0.2.2}/docs/golden-path.md

@@ -54,6 +54,12 @@ pcl jobs complete --root /tmp/pcl-demo J-0003 --summary "Designed test cases"
 pcl next --root /tmp/pcl-demo --explain
 ```
 
+When a job artifact is already recorded as evidence, link it during completion
+with `pcl jobs complete <job-id> --evidence E-00xx`. If the artifact is a raw
+agent output file at `.project-loop/evidence/agent-runs/<job_id>/output.md`,
+prefer `pcl ingest-agent-run` so PLH validates `agent-output/v1` and records
+the evidence row before marking the job passed.
+
 Expected checkpoint:
 
 - all jobs are terminal and passed;
@@ -93,6 +99,8 @@ Review:
 
 If validation fails or the generated artifacts do not match state, follow [recovery-playbook.md](recovery-playbook.md) before continuing.
 
+Status transitions are idempotent for exact same-state requests: repeating a goal, feature, test case, or task status command for the current status exits 0, returns `changed: false` in JSON, and records no new evidence or audit event.
+
 ## Executor Smoke Path
 
 Freshly initialized projects include a command-only workflow for dogfooding the

{project_loop_harness-0.2.1 → project_loop_harness-0.2.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "project-loop-harness"
-version = "0.2.1"
+version = "0.2.2"
 description = "Local control plane for agentic project development loops"
 readme = "README.md"
 requires-python = ">=3.10"

project_loop_harness-0.2.2/src/pcl/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.2.2"