codev 0.5.0

Changed

• BREAKING: codev decision supersede, codev decision deviate and
  codev decision promote now create a proposed decision, unsealed, like
  codev decision new: write or rework it, then run codev decision accept <ID> to make it take effect. Scripts that relied on these commands taking
  effect at once must add that step.
• codev decision supersede no longer modifies the old decision: it stays
  accepted, and in effect, until the new one is accepted. It now refuses a
  decision that is not accepted (predecessor_not_accepted).
• A deviation created by codev decision deviate only sets the inherited
  decision aside once it is accepted.
• codev decision deviate --json and codev decision promote --json no
  longer return bodySha256, since nothing is sealed.

Added

• codev decision accept marks the decisions listed in supersedes as
  superseded in the same step, leaving their body and seal untouched, and
  lists them in a new superseded field of its JSON output. It refuses a
  predecessor that is no longer accepted — for example, one another decision
  superseded in the meantime — with predecessor_not_accepted.
• Each artifact instruction of the spec-driven schema opens with an explicit
  role and its "Done when" criteria: product owner (proposal), QA analyst
  (specs), architect (design), tech lead (tasks).
• /codev-propose checks traceability between capabilities, spec files,
  scenarios and task verifications before presenting the plan, and fixes the
  gaps in the artifacts.
• /codev-propose then challenges the plan as a skeptical reviewer — need,
  scope, specs, decisions, assumptions, tasks, plus security, compatibility,
  operability, performance or accessibility lenses when the proposal's Impact
  touches them, and the project's rules: — and ends its summary with at most
  five "Points to challenge", or says none was found.
• codev init --inherit <SOURCE> (repeatable) declares inherited sources in
  the generated config.yaml — a git URL with an optional @<ref> (main by
  default) or a local folder — and pins the git ones in _codev/codev.lock
  right away. A pinning failure only warns (inherit_pin_failed); an invalid
  value is refused before anything is written (invalid_inherit).
• codev init integrates codev into the repository: a codev section in
  CLAUDE.md telling Claude Code to plan behavior changes with
  /codev-propose, and on GitHub a .github/workflows/codev.yml running
  codev validate --strict with codev pinned to the running version, and a
  codev section in the pull request template. On GitLab it prints a job to
  paste. Opt out with --no-claude-md, --no-ci, --no-pr-template or
  --no-integration. codev's text sits between <!-- codev:begin --> and
  <!-- codev:end --> markers and never replaces yours.
• codev update refreshes those managed sections and the managed workflow,
  and never adds one a project does not have.
• codev init --json and codev update --json gain an integration array.
• codev doctor [--json] [--strict] lists what the codev setup still lacks —
  rules, language, skills, specs, decisions, source pins, CLAUDE.md, CI,
  pull request template, validation — with the command or skill that fixes
  each item. codev init and codev status point to it when something is
  missing, and /codev-onboard relays its findings.
• The tech lead's "Done when" criteria of the spec-driven schema require the
  affected documentation to be updated in a task (or the plan to say none is),
  every spec scenario to be covered by an automated test, and tests to follow
  the project's existing suite, its language's conventions and its rules.
  The proposal's Impact names the documentation to update.
• /codev-propose's traceability check also requires an automated test per
  scenario and a documentation task when Impact touches documented behavior.
• /codev-apply writes tests like the project's existing suite, takes the
  test command from the configuration, manifest or CI instead of guessing it,
  and runs the full test suite once before reporting the change as done.
• /codev-configure proposes testing rules grounded in the project's existing
  tests, falling back on mainstream Rust, TypeScript/JavaScript, Python, Go
  and Java conventions when there are none yet.
• codev changelog generates release notes from the archived changes — Keep a
  Changelog, plain markdown or JSON — between two git refs, by default since
  the latest v* tag, and --write keeps a managed [Unreleased] section of
  CHANGELOG.md up to date; --release <version> turns it into a dated
  version block.
• Proposals carry a ## Release note section, categorized for end users;
  codev validate warns when an active change has none
  (release_note_missing) and rejects an unknown category or an empty item
  (release_note_invalid).
• codev doctor checks that CHANGELOG.md matches what codev changelog
  generates (changelog, a warning only).
• changelog.exclude in _codev/config.yaml leaves out archived changes
  already described by hand in CHANGELOG.md.

---

Install: curl -sSL https://raw.githubusercontent.com/mairistem/codev/main/install.sh | sh (macOS, Linux) · iwr -useb https://raw.githubusercontent.com/mairistem/codev/main/install.ps1 | iex (Windows)

Documentation: https://mairistem.github.io/codev/ · Full changelog: v0.4.0...v0.5.0