jpdev v0.8.0

jpdev v0.8.0

This release makes a check run proportional to a change, adds an opt-in duplication check, and
turns the kit's own policy vendor-neutral
(issue #33,
pull request #40;
issue #35,
pull request #41;
issue #42,
pull request #44;
issue #43,
pull request #45;
pull request #39).

Checks proportional to a change

jpdev check --changed [BASE] runs only the check-list steps that jpdev.json maps the changed
paths to, taking the paths changed since the merge base of BASE (the default branch when
omitted) and HEAD, in the working tree, the index and HEAD together. The whole list runs when a
changed path is unmapped, when jpdev.json, the manifest or the runner itself changed, when
nothing changed, or when the repository has no mapping. A missing merge base (a shallow clone,
an unknown base) is a refusal, never "nothing changed". The vendored runner
(scripts/dev/check.sh --changed) does the same through a vendored copy of the selection code
that the kit's tests and the release workflow hold to the library.

On pull requests the CI template now runs --changed against the base branch; a push to the
default branch and a manual dispatch run the whole list, and only those record release evidence.
jpdev version prints the kit checkout's description; an unknown option names it, so a kit
without a feature says so.

Duplication check

An opt-in duplication step reports copied blocks across a repository's declared languages, with
per-repository thresholds (min_tokens, min_lines, max_file_bytes), an explicit ignore block
for copies that are meant to stay, and a size bound with a named refusal when memory runs out.
Each token run keeps its most recent places and one place that spans min_lines lines on its
own, so a real pair is reported whatever sits between its two copies. Binary files and files
over the size bound are named and skipped. The kit runs the check on itself.

Policy

The model that builds or reviews is chosen by use case; a particular vendor's runner is one way
to run a build, not the default. The policy's "who builds and who reviews" section says what a
builder, a reviewer and a coordinator each own, independent of the tool that runs them.

Operating limits

The duplication check covers a copy only where at least one min_tokens run spans min_lines
lines on its own; a copy denser than that is covered by the recent-places window alone. Memory
across many files under max_file_bytes is bounded only by the refusal. jpdev clean keeps the
limits of v0.7.0.

jpdev v0.7.0

jpdev v0.7.0

This release adds explicit session cleanup and keeps builder temporary files beneath scratch
(issue #30,
pull request #31).

Session cleanup

jpdev clean defaults to a dry run with no implicit roots. Initialize an empty session-created
root with clean init, then explicitly seal completed disposable paths with clean seal.
Cleanup reports root-relative candidates, logical sizes, reasons, totals and per-path outcomes.
Deletion requires --yes and all ownership and safety checks to pass.

The default age threshold is seven days. Transcript candidates also have an inclusive 10 MiB
logical regular-file size floor, adjustable with --min-transcript-bytes N; zero disables that
floor. Exact paths in .jpdev-clean-keep protect reserves. Supported candidate kinds are
worktrees, reviewer directories/clones, transcripts, scratch associated with a removed worktree,
and shared caches whose base has no linked worktree users.

Cleanup requires explicit disposal evidence for every included file, including ignored,
untracked and review evidence. It refuses changed content, unpublished commits, tracked/index
changes, live process use, protected paths, symlinks, nested repositories, mount crossings and
unavailable verification evidence. Bare or saved Git metadata, inherited Git evidence
redirection, and assume-unchanged/skip-worktree index flags are refused. Git publication and,
where applicable, closed/merged pull-request evidence remain mandatory.

The tool checks evidence again after quarantine and during descriptor-relative removal.
Cache users and associated-worktree absence are checked throughout removal, including before
the final directory is removed. Git administrative entries and branch refs are retained.

Builder temporary files

jpdev codex run creates TMPDIR beneath the builder's effective scratch, replacing an inherited
temporary directory. The brief template and cleanup policy document session-prefixed scratch and
disposal ownership. Mutation copies exclude nested scratch, temporary storage and the copy
destination while retaining ordinary source siblings. Repository fixtures handle clone-local
temporary storage, and check summaries retain the names of failing test cases.

Operating limits

Existing unmarked roots cannot be adopted for cleanup. Complete initial Linux host process,
mount and root visibility is required; containers, sandboxes and inaccessible process evidence
cause refusal. System/global Git configuration is disabled during verification, so authentication
that depends on it may be unavailable and cause refusal.

A refusal during removal can leave a partially removed candidate. Remaining content is restored
when its original name is vacant, or retained in quarantine for assessment. The operation does
not provide transactional rollback or isolation from a malicious process with the same user
identity. See Scratch and cleanup
for formats and procedures.

This release is limited to the Devkit change. Adoption or re-vendoring in other repositories is
separate work.

jpdev v0.6.0

jpdev v0.6.0

Seven rows of the milestone, in four pull requests (#24, #25, #26, #28): the kit stops costing a build a run for things the repository already knows, and a review becomes one command.

What it holds

• CI after an automated branch update (#22, pull request #24). templates/update-branches.yml prefers an UPDATE_BRANCHES_TOKEN secret and falls back to GITHUB_TOKEN; on the fallback it waits for the updated head and dispatches ci.yml with the pull-request number and the head's SHA, so the required check and handover jobs run on that head. A fork's head is never dispatched: the run says so and fails visibly. A dispatch failure propagates; it is never mistaken for a merge conflict.
• The vendored handover check (#21, pull request #24). lib/handover_check.sh is vendored as scripts/dev/handover_check.sh with the kit's version line; the CI template calls that path; tests and the release gate hold both vendored scripts to their sources.
• The declared venv (#23, pull request #25). jpdev setup and jpdev check create the virtual environment dev.json names when it is missing, resolving the interpreter from the PATH or a pyenv version directory, else refusing with the version named; the path is validated as a relative child of the clone; every Python step runs with the venv first on its PATH and its summary names the interpreter.
• jpdev codex review (#13, pull request #25). A read-only Codex run from a review brief with the model, effort and sandbox explicit, no network unless --network is passed and logged, the record written to a file, the reviewed SHA printed, a refusal if the clone changed; jpdev codex brief-template --review prints the review skeleton with its two result lines.
• Brief words inside backticks (#12, pull request #26). check-brief treats text inside paired backticks as an identifier, path or command; a bare word is still refused with the same suggestion; unbalanced backticks exempt nothing; the product's own term left the list.
• codex run --add of a directory (#16, pull request #26). Every eligible file below the directory is committed; the handover files at any depth, ignored files and caches are left out; a directory with nothing to add is refused by name.
• Retained check logs (#8, pull request #28). Each step's output is kept under the scratch directory's logs/; when the log cannot be written the check still runs, its result is reported with the persistence failure named beside it, and the exit status stays the check's.
• Repository notes in briefs (#27, pull request #28). dev.json admits a notes list of plain sentences; brief-template prints them under ## This repository's notes; check-brief --build requires that heading when the manifest has notes.

What it does not hold

Running Codex itself in GitHub Actions; a second storage kind for anything; the re-vendor of adopting repositories, which follows this release as its own rows, the specification's first. The update template's fallback dispatch needs workflow_dispatch on the adopting repository's CI workflow, which the re-vendor brings.

jpdev v0.5.0

jpdev v0.5.0

Surgical rounds (#18, pull request #19): a fix round or a carry no longer costs what a fresh build costs.

What it holds

• Worktrees with shared caches. jpdev codex run --worktree <base> makes a git worktree off a base clone and points the sandbox's Go, npm and XDG caches at <base>/.jpdev-shared/; node_modules is linked from the base when the lock files match, otherwise the run is told to install. jpdev worktree add|list|remove manage them; remove refuses a worktree with uncommitted or unpushed work unless --force.
• A small-fix mode. jpdev codex run --small tells the builder to run only the check-list steps its change touches and leaves the whole list to CI; after the run the wrapper refuses to commit when the diff touched a path under dev.json's handover.shared_paths or boundary_paths, or changed more than JPDEV_SMALL_MAX_LINES lines (default 80).
• Carries without an agent. templates/update-branches.yml, vendored by adopting repositories, updates every open pull request branch from the default branch on each push and labels carry needed on a conflict; jpdev carry --pr N merges the default branch into the branch, commits and pushes when nothing conflicts, and otherwise starts a Codex run from a generated carry brief (templates/carry-brief.md).
• Resuming a builder's thread. jpdev codex run --resume <thread> continues a previous Codex thread for the fix round that follows a review; every run records the thread id the CLI reports in .jpdev/output/thread. A builder stopped by a safeguard is still never resumed.
• The handover job in CI. templates/ci-check.yml gains a handover job: the boundary-path diff against the base must be additions only unless the pull request body says Boundary change: yes, and the manifest's handover.schema_probe command runs when set. The logic lives in lib/handover_check.sh.

What it does not hold

Running Codex itself in GitHub Actions; jpdev codex review (#13); the handover files swept by --add of a containing directory (#16); the identifier exemption in the word list (#12); the usage text on the recorded thread id (a wording row). The adopting repositories re-vendor the workflow, check.sh and the CI template after this release.

jpdev v0.4.0

jpdev v0.4.0

The turnaround rules move into the kit (#14, pull request #15).

What it holds

• templates/AGENTS.md (and the generated CLAUDE.md) gain the section "Before you hand over": the self-checks a builder runs on its own head before the commit message (the boundary paths unchanged, every schema member carried by a vector, both languages agreeing on shared vectors, every mutation row caught, every refusal event valid on malformed input, resumed runs carrying new checkpoint members, the design's words matching the code), the check list run with --only while iterating and whole once, shared paths changed by appending only while a sibling build is open, and the severity line.
• dev.json gains the optional handover object: boundary_paths and shared_paths. jpdev check prints one line with the counts of both when they are set.
• templates/codex-brief.md gains the section ## Before you write msg.txt. jpdev codex check-brief --build refuses a build brief without that heading; jpdev codex run uses the --build form.
• jpdev codex run exports the sandbox's scratch, lock and cache paths under the clone for the Codex process (JPDEV_SCRATCH, JPDEV_LOCK, GOCACHE, GOFLAGS=-mod=readonly, npm_config_cache, XDG_CACHE_HOME), each only when it is not already set, creates the directories, and refuses an --add that names one of them.
• docs/policy.md gains the "Turnaround" section: two builds on sibling branches, the coordinator carrying main, the builder's self-checks, the review re-read tier, CI green before any review. docs/adopting.md says what handover means for a builder.

What it does not hold

jpdev codex review (#13), the identifier exemption in the word list (#12), and the handover files staged through --add of a containing directory (#16). The repositories that vendor the pair re-vendor it after this release.

jpdev v0.3.0

jpdev v0.3.0

The third release of the development kit: Codex CLI sessions run from the same briefs as Claude sessions, and the push form is one command.

What it holds

• jpdev codex run (#9): runs a Codex CLI build from a brief with the model and effort always explicit, in a workspace-write sandbox with network access, stdin closed, the transcript logged; after Codex returns, the wrapper stages the tracked changes (and only the paths named with --add), commits with the DCO sign-off from Codex's msg.txt (adding the Co-Authored-By: Codex trailer where missing), pushes with the credential-helper form, and opens the pull request from pr.md; --no-commit, --no-push, --no-pr stop earlier; a clone on main is refused. Found on the first real run: Codex's sandbox keeps .git read-only, so the git part is the wrapper's.
• jpdev codex check-brief (#9): refuses a brief that carries a word from the kit's list (extendable through JPDEV_CODEX_WORDS) and suggests a neutral phrasing; a term split across lines or hyphenated is matched too (from the review). jpdev codex brief-template prints the brief shape Codex expects.
• jpdev push [branch] (#6): the credential-helper push form in one command, refusing every force form; templates/AGENTS.md and CLAUDE.md state the form and name the command (adopted repositories re-sync their agent docs).
• -mod=readonly (#7): a Go step can no longer rewrite go.mod; a kit test holds go.mod byte-identical across a step.
• The policy (docs/policy.md): the cross-vendor rule: Codex builds non-boundary issues from accepted designs and briefs and Claude reviews them; Claude builds boundary decisions and Codex reviews them when its quota allows.

Adopting repositories

Re-vendor scripts/dev/check.sh from templates/check.sh at this tag and re-sync AGENTS.md/CLAUDE.md from templates/AGENTS.md so the push form is stated.

Installing and verifying

Download the tarball and checksums.txt from this release, check the digest, and verify both attestations as docs/releasing.md describes before linking bin/jpdev into your PATH.

jpdev v0.2.0

jpdev v0.2.0

The second release of the development kit, the first through its release workflow, and the first public one.

What it holds

• The kit is public. The repository carries the contributor files the other Judgment Pack repositories carry (CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, NOTICE, the pull-request template, Dependabot for the actions), the release workflow (an annotated tag on main, the CI jobs at the tag, a reproducible git archive tarball with checksums.txt, provenance attestations for both, a draft from the notes, publication behind the release environment), and docs/releasing.md with the verification form.
• The kit on itself. dev.json, scripts/dev/check.sh, AGENTS.md and CLAUDE.md from its own templates; the lint and tests jobs run through the runner.
• The manifest's venv applies to every step (#3): a node or go step that calls a python script now sees the venv's interpreter first on the PATH, as the python steps did; the toolchain still decides the cap. Found by the spec and gateway adoption reviews.
• The runner template records its version (#3): templates/check.sh line 2 names the kit version; the release workflow asserts it matches the tag and that the kit's own vendored copy is byte-identical. Repositories that vendored the v0.1.0 template carry no such line until they re-vendor.
• The go toolchain takes a version (#2): dev.json can name the Go release a repository is measured on; templates/ci-check.yml reads it and falls back to go-version-file; jpdev setup selects it where installed and says so where not.
• The tarball holds examples/, which the shipped README.md and docs/adopting.md point to (from the v0.2.0 prep's review).

Adopting repositories

Re-vendor scripts/dev/check.sh from templates/check.sh at this tag so the line-2 version is present, and add go.version to dev.json where CI pins a Go release. Nothing else changes for an adopted repository.

Installing and verifying

Download the tarball and checksums.txt from this release, check the digest, and verify both attestations as docs/releasing.md describes before linking bin/jpdev into your PATH.