Skip to main content
gitvow sessions export is the other artefact. For one repository it gathers each session’s transcript as the agent wrote it, the ledger entry, the session notes on this repository’s commits, and the working-tree snapshots as patches, byte for byte, into a bundle of kind sessions-raw. Nothing in it is redacted. It is for a store your organisation runs, which holds it complete under your own retention and redacts it when someone reads it.

Who can take it

  • A store your organisation runs, when its operator has enabled sessions-raw. Otherwise it answers with a refusal and the reason.
  • Nothing anyone else hosts. A hosted store refuses this kind under every configuration; there is no flag.

Look first

Nothing is written by --dry-run. A transcript that is not on this machine is named as missing, never guessed.

Send it

--to names a sink from gitvow sinks. An http sink speaks the store protocol, the same verbs gitvow sync uses; a dir sink receives a copy under <source>/sessions/<digest>/. A git sink refuses: every clone would replicate the sessions and nothing would scrub them. An unreachable store is reported, not queued; there is no outbox for sessions.

What is in the bundle

manifest.json lists every part with its hash and size and the sessions it covers; attestation.json states that the bundle is unredacted, whether it is complete, who exported it and what never produces it.

What this is not

  • Not gitvow sync. The collector refuses to move a sessions bundle, whatever the sink.
  • Not switched on by a committed file. .gitvow/export.json governs the record bundle and cannot name this.
  • Not run by a hook. A person types it.
The people whose sessions these are should be told before the first export, by the organisation that runs the store. The attestation records who ran the command; it cannot record that the notice was given.