kapi apply

$ kapi apply [flags] [CHANGESET]

Apply a typed change-set: the write sibling of 'kapi inspect'. Each entry is one reviewed change: a content edit, an asset edit (term, content-memory pair, voice rule, recipe field), or a review outcome (kind:"review"). Content edits land through the same byte-faithful round-trip the engine's writers use (structure and inline codes preserved), drift-guarded by content_hash; asset edits are written into their committed source artifact and the existing import compiles them into the cache; a review outcome is recorded as unit state in the project store.

A content memory pair (kind:"memory") is recycle leverage for future translation. It does not promote a unit to reviewed. To approve a translated unit, use a kind:"review" entry addressed by its file/id/locale (as 'kapi status --review' lists it), with status "reviewed" (default) or "signed-off"; the unit state is staged in the project store and is bound to the translation's content hash, so a later edit drops the unit back below reviewed. 'kapi commit' writes it into the committed record under .kapi/state/.

A comment edit (kind:"comment") rewrites one code comment, addressed by its file and the id 'kapi check' reports for it, such as func/Parse, in Go and in the languages a comment plugin reads (TypeScript, TSX and JavaScript among them). Its text is the comment's prose without comment markers. It carries the comment_sha256 that 'kapi check --json' reports for the comment, or the prose as read in current_text, and a comment that changed since is refused. Every byte outside the comment stays as it is, the result must parse, and the language's formatter must agree. Running that formatter runs code the project controls, so kapi asks once per project, in a terminal, and records the answer. A directive, a generated file's comment, and text that drops or adds a code block or reference are refused with a reason and write nothing. Each written file is checked again over what changed, and the findings are reported beside the edit.

The change-set is JSONL (one entry per line), read from CHANGESET or, with no argument or "-", from standard input. Content entries name their own file, so apply writes those files in place; --diff previews content and comment changes and writes nothing. No AI provider is required.

Commandapply

Groupwork

Try it

Runs in your browser against a small sample file. Edit the command before running, or press Run to execute it as shown.

$ kapi inspect report.docx --jsonl | edit-the-text | kapi apply

Flags

Flag	Type	Default	Description
--diff	bool	false	preview content and comment changes as a unified diff and write nothing
--encoding	string		input/output encoding
--format, -f	string		input/output format for content files (default: auto-detect)
--in-place, -i	bool		keep a backup of edited content files with --in-place=.bak
--json	bool	false	print the apply report as JSON
--project, -p	string		path to a kapi.yaml project recipe or its directory (auto-discovered from cwd if omitted)
--source-lang	string		source language (e.g. en, en-US; defaults to the project's source_language, else en)

More examples

$ kapi apply changeset.jsonl

$ kapi apply changeset.jsonl --diff

$ kapi status --review --json | approve-units | kapi apply

$ kapi apply changeset.jsonl --in-place=.bak

echo '{"kind":"comment","file":"parse.go","id":"func/Parse","lines":{"first":3,"last":4},"comment_sha256":"<from kapi check --json>","text":"Parse reads the input."}' | kapi apply

← Back to the Command Reference