Git-native workflow

Parlance has no database, no cloud service, and no accounts. Your repository is the project. That's not a limitation being spun — it's the design bet the whole tool is built on: everything teams struggle with in narrative pipelines (versioning, merging, review, backup, tooling access) is already solved for plain files in version control.

Files that diff like they mean it

• One JSON file per entity. A dialogue is a file; a character is a file. Git history answers "what changed in this scene" per scene, not per database-dump.
• Canonical serialization (sorted keys, stable formatting — see schema-first data) means a one-line edit produces a one-line diff.

   "text":
-  "I sell tinctures. Nothing stronger."
+  "I sell tinctures, magistrate. Nothing stronger —
+   nothing that would do *that* to a man."

• Editor metadata never pollutes content. Canvas node positions live in *.layout.json sidecars that are gitignored — your graph arrangement is a personal concern, and data/ stays pure story. Deleting a sidecar just re-runs auto-layout.
• Review data can't break the build. The review/ directory is invisible to the runtime, the loaders, and the validator — a stale comment can never fail a narrative build.
• If two writers (or a script) touch the same file, the editor's stale-load detection catches the conflict at save time (a 409 — reload and re-save) instead of silently clobbering.

Review: reading someone else's branch

The Review surface turns a branch into a reviewable story, using nothing but git — a two-person team on plain clones gets working review with no server anywhere.

Setting this up for a team of writers? The collaboration setup guide covers signing them in (GitHub, GitLab, Bitbucket), the one-time studio setup, and exactly what the security model gives you.

• Roles are decided by git, not modes. Have the branch checked out? You're its author. Otherwise you're a reviewer, reading a snapshot — your own working tree is never touched.
• Narrative diffs, not file diffs. "2 nodes added, 1 line edited, offer re-gated" — per-entity before/after lines, flags introduced or retired, and the validation delta.
• Play the branch. Reviewers run the branch's own content in playtest — hear the scene as it actually plays before saying anything about it, with a 💬 on every transcript line that opens a comment anchored to that exact node.
• Comments anchor to story, not line numbers — a node, a choice, a field. Renaming things doesn't orphan discussion silently; threads get flagged stale anchor instead.
• Suggestions are the reviewer's edit: they propose replacement text, the author applies it with one button. Content edits stay with one writer, which is what keeps review data conflict-free.
• Verdicts record what was actually read. Approve / request-changes is stamped against a commit; push more work and the review says "the branch has moved since this verdict" rather than showing a stale tick.
• Publishing an approved draft (Approve & publish… or Publish…) merges it into the base branch on the remote from whatever branch you are on, without touching your working copy. It merges cleanly or not at all — conflicts are resolved in git, not inside a narrative editor.
• Drafts give writers branches without git. Drafts → New draft creates a branch for the piece of work, Send for review commits and pushes it with a review request, and Clean up deletes the branch once it is published — only after git confirms it is merged.

What Parlance deliberately isn't

It is not a git client. The only branches it creates are writers' drafts, and beyond that there is no conflict resolution, no history editing, no PR sync. Conflicts and history stay in the tools built for them; Parlance adds the narrative-shaped layer those tools can't see.

And because it's all just files in CI's reach…

the same repo that holds the story can gate on the story: parlance ci-check runs the full validator headless, and route fixtures replay scripted playthroughs with assertions. Narrative regressions fail the build. That's the whole loop.