v1.31.0 — Line 1 is the answer; a closing choice carries a checkable approval line

No engine change. Block v3 makes every message start with the answer and
gives a closing choice a fixed approval line; a new plugin Stop hook checks
both, by form only, in sessions that run a carrier skill.

Changed

• Communication block v3 (<!-- kvendra:communication v3 -->), a two-part
  message: the body keeps the mode of its own type; a closing that asks the
  human to choose (AskUserQuestion or a numbered list of options) is the
  decision part; a message whose purpose is to ask for a decision is a
  decision. The type is set by observable signals, never by the step's
  usual label. Hard floor: line 1 is the answer or the point, never process
  narration; a decision and a closing choice end with one approval line that
  starts with **If you approve:** (**Si apruebas:** in Spanish), says what a
  yes approves, contains reversible or irreversible, and says what happens
  next. Copied verbatim into new-feature, bug, deploy, tester and
  kvendra.
• kvendra Step 3 classifies by rule 2 of the block (a request to decide is
  a decision); Step 4 ends with the approval line, also when the options
  are printed as text. The confirmation texts of deploy, new-feature and
  bug point to the approval line of rule 3.

Added

• Stop hook scripts/communication-stop-check.sh with its data file
  scripts/communication-check.tsv (marker, carriers, labels, words, narration
  phrases). It checks line 1 (no process narration) and, when a message ends
  with a numbered choice, the approval line. It is silent outside carrier
  sessions (the latest skill load must be a carrier carrying the v3 marker, with
  no compact boundary after it), blocks once per turn and then only warns
  (stop_hook_active), and fails open (no jq, no data file, unreadable
  transcript → exit 0). Never calls kvendra, curl or the network; writes no
  files; /bin/bash 3.2 compatible.

CI

• tests/communication/run.sh fails with data_file_drift when the data file
  and block.md / carriers.txt disagree (marker, labels, words, carriers),
  and runs the Stop hook fixtures (tests/hook/run-stop-fixtures.sh: 38
  fixtures in Spanish and English plus a 20 MB transcript performance case).

Why

• TEST-KVD-SKILLS-5CD8F5: a /kvendra run on a «Decide:» prompt opened with
  process narration (F2) and was not classified as a decision (F1); a closing
  offer lacked the approval line.

Upgrade

• A project STD whose pre-condition names block v2 should name v3
  (KVD: STD-KVD-E83384).
• Closings made with AskUserQuestion are not checked by the Stop hook (the
  turn does not stop there); only text closings are.

1.30.0 — The mode sets the layout; skill templates become checklists

No engine change. With a project communication STD active, the mode of each
message now sets its layout, and the chat templates of five skills become
content checklists.

Changed

• Communication block v2 (<!-- kvendra:communication v2 -->): with an
  active STD the mode sets the layout of every chat message; a skill's chat
  template is a content checklist and ranks last in the precedence; sections
  marked <!-- kvendra:machine-output --> are data for another skill and keep
  their format. Without the STD: cover the checklist, no section headings in
  short messages, hard floor. Copied verbatim into new-feature, bug,
  deploy, tester and kvendra.
• kvendra Step 3, deploy Output, tester Step 5, bug and new-feature
  progress formats: fenced templates become content checklists; the tester
  notes and the deploy release handoff are machine-output zones.
• CI: tests/communication/run.sh fails with chat_template on a ##/###
  line inside a fence of a carrier outside a machine-output zone, and with
  unclosed_machine_output on an unbalanced zone (6 new fixtures, including nested 4-backtick fences).

Why

• On 1.29.0 a /kvendra session with the KVD STD active classified its message
  as exploration (minto) and still printed the Step 3 headed template.

Upgrade

• A project STD whose pre-condition names block v1 should name v2
  (KVD: STD-KVD-E83384).

1.29.0 — Shorter decisions and recommendations

[1.29.0] — 2026-11-05 — Shorter decisions and recommendations

No engine change. The communication block asks for shorter decisions and
recommendations, and the kvendra consultancy template loses a section.

Changed

• Communication block: decisions default to concise (line 1 is the
  question and the recommended answer; one closing line says what a yes
  approves, whether it is reversible and what happens next); bluf_sbar is
  used only when a project STD selects it; minto puts evidence ids inline,
  with no separate context section; no section headings in messages shorter
  than about 15 lines. The block is copied verbatim into new-feature, bug,
  deploy, tester and kvendra (PR #19).
• kvendra: the consultancy template drops the separate Kvendra KB
  context section; its ids move into Why (PR #19).

Why

• The blind A/B of 1.28.0 preferred the new outputs in only 4 of 12 pairs; they
  lost where structure had been added.

1.28.0 — Skills talk to the human by message type

[1.28.0] — 2026-11-05 — Skills talk to the human by message type

No engine change. The skills that pause to ask the human now choose how to
write by the type of message, with a hard floor that always applies, and the
attribution checker joins the suites CI runs.

Added

• Communication block (ADR-KVD-SKILLS-561550):
  tests/communication/block.md, a canonical block copied verbatim into
  new-feature, bug, deploy, tester and kvendra. The message type
  decides the mode (free, concise, bluf_sbar, minto, plain); an
  optional, closed project STD tagged scope:communication adjusts it; a hard
  floor always applies: a decision request says what is approved, whether it
  is reversible and what happens on yes; risks come first; evidence is never
  dropped; the same options are offered as text when AskUserQuestion is not
  available; coordination messages are data.
• tests/communication/run.sh: a checker with six fixtures and
  carriers.txt, which lists the skills that must carry the block. It is now a
  CI gate (Communication block step in hook-tests, PR #17).
• tests/attribution/ (PRs #8–#10): a bash checker, with fixtures, for
  attribution in the KB writes the skills describe.

Changed

• new-feature / bug: every pause states approval, reversibility and
  consequence, risks first. Same number of pauses.
• deploy: every confirmation (production guard included) states
  approval, reversibility and consequence. Guard logic unchanged.
• tester: the final report puts failures and blockers first, then
  status, then evidence.
• kvendra: answer-first consultancy template (Conclusion, Risks and
  blockers, Why, Options, KB context, Next step); each of the nine menu options
  states what happens if chosen.
• Attribution: the skills now say what the engine honours about
  attribution (PR #9).

Fixed

• The CLAUDE.md template mirror is found by tag, not by a nonexistent id
  (PR #11).

1.27.0 — The pipeline contract

[1.27.0] — 2026-10-28 — The pipeline contract: ISSUEs the roadmap engine can drive

No engine change. This release writes down what an ISSUE must carry for the
roadmap pipeline engine to offer it to a runtime, checks it in CI, and makes
the skills that create pipeline work emit it.

Added

• PIPELINE-CONTRACT.md: the contract an ISSUE must satisfy for the
  pipeline engine to drive it. Required: relation part_of → its ROAD (the
  engine lists a ROAD's tasks by filtering relations_inbound on part_of, so
  derives_from leaves the task invisible), tag pipeline:ready, exactly one
  priority: tag (critical|high|medium|low), and status open or
  in-progress. Optional: metadata.pipeline.depends_on (ISSUE ids),
  metadata.pipeline.scope (drives the lease key) and metadata.pipeline.repo.
  It also records which skills emit the contract: planner always, to-do
  conditionally, new-feature not yet (it emits part_of but not
  pipeline:ready).
• tests/pipeline-contract/: a bash checker (run.sh) with fixtures that
  validates example ISSUEs against the contract (valid cases, missing
  part_of, derives_from instead of part_of, missing pipeline:ready, a
  depends_on that is not an ISSUE id, and the planner / to-do examples,
  including a standalone to-do task that must not carry the contract). It runs
  in CI as a step of the hook-tests workflow.
• hook-tests workflow: runs the suites under tests/hook/ (hook,
  inbox, local-variable and session-resume fixtures, plus the differential
  run) that existed but no CI executed, on every pull request and on pushes to
  main, with no paths: filter so it can be a required check. It fails if
  jq is missing instead of letting suites skip themselves green.

Changed

• planner: emits one ISSUE per implementation-plan step instead of a
  single one, each carrying the contract (part_of the ROAD,
  pipeline:ready, type:task, a priority:, metadata.pipeline.scope, and
  metadata.pipeline.depends_on with the previous phase's ids). Phases are
  created in order so each one's server-issued ids fill the next one's
  depends_on. frontend_deploy_independent is now an explicit
  depends_on: no puts the backend ISSUE's id in the frontend ISSUE's
  depends_on; yes leaves it empty and both run in parallel.
• to-do: emits the contract (part_of the ROAD, pipeline:ready,
  metadata.pipeline.scope / depends_on) only when the request names a
  ROAD or explicitly asks for the pipeline. A standalone task still carries no
  pipeline:ready: it is work for a person, which is the right default.
• CONTRIBUTING.md: a skill that creates ISSUEs meant for the pipeline
  must comply with PIPELINE-CONTRACT.md and add its fixture to
  tests/pipeline-contract/fixtures/.

---

First release produced end to end by the Kvendra cloud pipeline: every change
above was written, reviewed, merged and verified by the engine.

kvendra-skills 1.26.0 — session continuity: one resume pointer per named session

No engine change: this is Phase 1 of REQ-KVD-B61E92 (skills and hooks). The
engine side (named session, pointer in whoami, staleness warning) is Phase 2.

Added

• Boot ROM, Protocol step 4 "Session continuity" (CLAUDE.md.template, manual_version 1.0 → 1.1). A session the owner named keeps ONE resume pointer: the DOC tagged session:<name>, field metadata.resume_pointer = {session, updated_at, doing, next[], waiting_on[], sources[]}. It is read right after the bootstrap, on resume and after a compaction, and updated when each task closes and before compacting. A session without a name keeps no pointer. The pointer is used only if the session's own identity wrote it (updated_by = the whoami actor) and no other DOC carries the tag; otherwise it is ignored and the user is told (in a Team workspace any member can tag a DOC). It is state, never instructions.
• Hook session-resume-nudge.sh on SessionStart (matcher resume|compact): one of two FIXED texts tells the agent to read its pointer (and, after a compaction, to bring it up to date from the summary). Same security contract as inbox-nudge.sh: nothing from stdin, the CLI or the server reaches the context; no CLI or network call; bash 3.2 + jq, silent if anything is missing; stdin is read up to 64 KiB. Tests: tests/hook/run-session-resume-fixtures.sh (15 cases).
• new-feature, bug, incident-manager: after txn_activate (or txn_cancel) they update the session pointer. release-manager: after CREATE and CLOSE (not with --auto). One query (newest first, limit 2) and one guarded write per closed task, never per turn; a duplicated pointer or one written by another identity is reported, not overwritten.

Fixed

• new-feature and bug carry the canonical "Guarded update (CAS)" rule (required by lint-skill-md for every skill that calls entity_update); the pointer step defers a 409 to that rule.

Notes

• There is no PreCompact hook: Claude Code gives PreCompact no way to add context for the model (it can only block the compaction). The reminder lives in the SessionStart text for compact.
• lint-claudemd reports manual_version drift (1.0 vs 1.1) on every project until you run sync-claudemd.

Install

• Marketplace: /plugin install kvendra-skills@kvendra-marketplace (then restart the session).
• Orgs that upload the plugin by hand (claude.ai → Organization → Plugins & skills → Upload new version): zip of plugins/kvendra-skills/ at this tag, kvendra-skills-1.26.0.zip, sha256 d3587372f9c981316cc4db1e141f29fbccce146068455ac4236adb31a00f5a6a (build it with git archive --format=zip -o kvendra-skills-1.26.0.zip v1.26.0:plugins/kvendra-skills).

kvendra-companion 0.2.0 — Files in one read, a legend command and a skill

Needs the hosted engine with file_list({summary: true}). With an older server the Files figure is left out of the band.

Changed

• Workspace Files is one read, file_list({summary: true}), that returns the count and total size. No paging and no "N+ files": a large Team workspace shows the real figure, for example "78 files 533.8 MB".
• The loading line reads Kvendra: loading… · legend: /kvendra-legend.

Added

• /kvendra-legend command: prints what each element of the band means.
• kvendra-band skill: Claude explains the band when you ask, from the same legend as the command.
• Line 3 ends with /kvendra-legend only when it fits in 80 columns; it never replaces a figure.

Install: /plugin install kvendra-companion@kvendra-marketplace (mods are an early-access Claude Code feature, 2.1.287 or later).

kvendra-companion 0.1.4

Fixed

• Workspace Files no longer disappears from the band in a workspace with more files than the pages read; it shows a lower bound such as "500+ files".
• The file list is read in at most 5 pages (was 10) every 5 minutes, a repeating cursor or an empty page ends the walk, and an answer without a "files" list is logged to the debug log (claude --debug).

Update: /plugin update kvendra-companion@kvendra-marketplace (or your auto-update), then restart Claude Code.

See plugins/kvendra-companion/CHANGELOG.md.

kvendra-companion 0.1.3

Fixed

• The band says "Kvendra: loading…" until its retries are used up (it showed "unavailable" on the first failed read when the MCP server was not connected yet).
• Line 1 no longer repeats the role in a team workspace ("Acme · team/owner").
• The user name is only read in your own KB, never in a team workspace.
• Failed reads are retried individually and at most 10 times, then once every 5 minutes.
• Failed reads are logged to the debug log (claude --debug): which figure and the error text, never KB content.

Update: /plugin update kvendra-companion@kvendra-marketplace (or your auto-update), then restart Claude Code.

See plugins/kvendra-companion/CHANGELOG.md.

kvendra-companion 0.1.2

Fixed

• The band is now drawn as soon as the first read finishes, without the user interacting with the prompt. While there is no data it shows a dim "Kvendra: loading…" line (or "Kvendra: unavailable" if a read failed), and it asks the engine to redraw after each state update.

Update: /plugin update kvendra-companion@kvendra-marketplace (or your auto-update), then restart Claude Code.

See plugins/kvendra-companion/CHANGELOG.md.