@mean-weasel/lineage 0.1.4 → 0.1.6

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## 0.1.6
+
+- Add per-image re-roll attempt history with stack inspection, previous-attempt selection, and promotion back to the current/top attempt.
+- Add CLI and agent-facing re-roll commands for marking, listing, planning, importing, and cancelling one job per target image.
+- Package public-safe Swissifier re-roll PNG fixtures and manifest metadata so the demo canvas shows multi-attempt nodes out of the box.
+- Harden project switching, lineage workspace fallback, and backend attempt invariants around re-roll histories.
+
+## 0.1.5
+
+- Add graph orientation controls for lineage views and CLI flows, including browser coverage for orientation behavior.
+- Improve agent claim visibility with workspace/content occupancy badges, claim lifecycle controls, and release claim smoke coverage.
+- Harden lineage claim enforcement for explicit child workspaces and `project_channel` claims so scoped claims cannot authorize broader writes.
+- Make local startup helpers durable with tmux-backed Makefile commands.
+
 ## 0.1.4
 
 - Implement target-scoped agent claims for lineage and content-post agent writes, including claim lifecycle CLI/API commands, heartbeat/release/revoke/transfer controls, and token-redacted read APIs.

package/README.md

@@ -54,6 +54,12 @@ lineage agent claim --project demo-project --scope lineage_workspace --target de
 export LINEAGE_CLAIM_TOKEN='claim_abc.secret_xyz'
 ```
 
+Agents can inspect the current lineage graph without a claim:
+
+```bash
+lineage agent graph --project demo-project --root <root-asset-id> --json
+```
+
 Keep the claim fresh and pass it to mutating commands:
 
 ```bash
@@ -62,6 +68,17 @@ lineage link-child --project demo-project --root <root-asset-id> --child <child-
 lineage agent release --claim-token "$LINEAGE_CLAIM_TOKEN" --json
 ```
 
+For re-roll work, mark the target, have the agent plan/import one replacement
+attempt, and cancel only when the request should be abandoned:
+
+```bash
+lineage reroll mark --project demo-project --root <root-asset-id> --target <target-asset-id> --notes "Fix distorted text" --confirm-write --json
+lineage reroll list --project demo-project --root <root-asset-id> --json
+lineage reroll plan --project demo-project --root <root-asset-id> --target <target-asset-id> --prompt "Regenerate with clean readable text" --json
+lineage reroll import --project demo-project --job-id <job-id> --file <.asset-scratch-file> --confirm-write --json
+lineage reroll cancel --project demo-project --root <root-asset-id> --target <target-asset-id> --confirm-write --json
+```
+
 The app-created claim-aware handoff packet includes the same token export,
 heartbeat, inspect, and write commands. Raw claim tokens are not shown in the
 read-only Agents view.
@@ -127,12 +144,13 @@ For local release validation:
 
 ```bash
 npm run release:dry-run -- --tag next
+npm run release:claim-smoke -- --package @mean-weasel/lineage@next
 npm run release:next
 npm run release:dry-run -- --tag latest
 npm run release:latest
 ```
 
-The release script verifies package metadata, changelog version coverage, public-readiness scans, install smoke, browser smoke, audit, and package contents before publishing. GitHub Actions runs CI on pull requests and `main`; publishing is manual through the Release workflow.
+The release script verifies package metadata, changelog version coverage, public-readiness scans, install smoke, browser smoke, audit, and package contents before publishing. Promotion also installs the candidate package and runs a claim lifecycle smoke that creates a target claim, proves missing-token writes fail, proves matching-token writes succeed, verifies read surfaces do not expose the raw token, and proves release invalidates the token. GitHub Actions runs CI on pull requests and `main`; publishing is manual through the Release workflow.
 
 Use the Release workflow operations this way:
 
@@ -148,11 +166,13 @@ Source checkouts and installed packages include a synthetic public demo catalog
 
 If you create a real `demo-project/assets/catalog.json`, that root project catalog overrides the packaged fixture. The fixture keeps S3-shaped metadata for realistic catalog structure, but default previews are generated local SVG data URLs and do not call storage.
 
-Lineage also includes a lightweight Swissifier rich-demo manifest at `fixtures/demo-project/lineage/swissifier-rich-demo.json`. The manifest stores only synthetic metadata, checksums, graph edges, layout positions, and selected next-variation bases. It does not include generated PNG media or any local SQLite state.
+Lineage also includes a lightweight Swissifier rich-demo manifest at `fixtures/demo-project/lineage/swissifier-rich-demo.json`. The manifest stores only synthetic metadata, checksums, graph edges, layout positions, and selected next-variation bases. It does not include local SQLite state.
+
+The package intentionally includes three public-safe synthetic Swissifier re-roll PNG fixtures in `fixtures/demo-project/lineage/swissifier-rerolls/`. They are the only generated PNG media committed with the rich demo, and each file is pinned in the manifest by filename, SHA-256, size, content type, prompt, and demo generation job id so public-readiness and package-smoke checks can prove the fixture is hermetic.
 
 To hydrate the Swissifier demo with real images, use the Demo seed menu's Swissifier `Download media` control. Lineage downloads `swissifier-rich-demo-v1.tar.gz` from the [v0.1.2 GitHub release](https://github.com/mean-weasel/lineage/releases/tag/v0.1.2), verifies the archive checksum, safely unpacks the PNGs into local scratch storage, and then verifies each PNG checksum before loading the rich demo.
 
-Future rich-demo media packs should follow the same split: commit only the lightweight manifest changes, attach the generated media archive to the GitHub release for the app version that first references that archive, then pin the public release URL, archive size, and SHA-256 in the manifest. If a later app release reuses an unchanged media pack, keep the manifest pointed at the original release asset instead of duplicating the archive.
+Future rich-demo media packs should follow the same split unless a small synthetic media exception is explicitly documented and manifest-pinned like the packaged re-roll PNGs: commit lightweight manifest changes, attach generated media archives to the GitHub release for the app version that first references them, then pin the public release URL, archive size, and SHA-256 in the manifest. If a later app release reuses an unchanged media pack, keep the manifest pointed at the original release asset instead of duplicating the archive.
 
 For manual verification or offline restore, the expected archive checksum is: