LineBreak security gate at the git/CI boundary: serves a repository's human-approved spec (.linebreak/spec/) to MCP clients over stdio, read-only and fully offline. Dependency CVE scan + AI SAST, human-approved overrides, git-native audit records.
Six tools with clear, domain-specific naming (list_stories, get_story, next_story, set_story_status, check_story, spec_status). All have descriptions (avg ~180 chars, within 10 - 1024 baseline). Input schemas present with type declarations. However, output schemas are not documented in the visible code, only return type hints (dict[str, Any]). Parameter descriptions are present but sparse (e.g., 'story_id' lacks format guidance). Error handling is implicit (delegated to bridge module, not visible). No tool annotations (readOnlyHint/destructiveHint). Composition is sound: each tool has one responsibility; set_story_status is the only write operation and is clearly marked. Naming follows verb_noun convention and is unambiguous.
Run this story's acceptance criteria against the working tree with the SAME engine as the merge gate (`linebreak-gate check`). Returns pass | fail | needs-signoff | overridden | error per criterion, or release-only for a `when: release` criterion when stage is "pr" (not evaluated; the release gate owns it). Use stage "pr" before pushing a pull request so checks against a shared staging environment do not run from your machine; "release" (default) evaluates everything.
One approved story in full: title, epic, and every acceptance criterion with its id, statement, and check (type: build | tests | command | manual; optional payload; optional when: release, meaning the criterion is checked only by the release gate, not on PRs). Read this BEFORE implementing the story: the criteria are the approved definition of done.
All approved stories in this repository: id, title, epic, local status (todo|doing|review|done), and how many acceptance criteria each carries. The list IS the approved scope — nothing else is in spec.
The next approved story that is not yet done, per local story state. Use this to pick up work without guessing at priorities.
Record story progress: status is doing | review | done. Writes LOCAL story state only (the repo's tracker-sync artifact) — never a configured external tracker, and never the approved criteria.
Output schemas not documented. All tools return dict[str, Any] with no field-level documentation. LLMs cannot infer what fields to expect or plan downstream calls.
Parameter descriptions are minimal. 'story_id' and 'status' lack format guidance, valid enum values, or constraints. 'stage' parameter in check_story mentions 'release (default) or pr' but no enum constraint visible in schema.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Five tools are read-only; one (set_story_status) is destructive. Annotations would help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Is there an approved spec bundle: version, source phase, approver, story count, and the approval signature state (verified | invalid | signed-unverified | unsigned), verified entirely offline.
Error handling is opaque. Descriptions mention 'pass | fail | needs-signoff | overridden | error' for check_story but no guidance on what to do if a criterion fails or if the story is not found. Recovery paths are not documented.
set_story_status accepts 'comment' as optional but no guidance on when comments are required or what format they should follow. No confirmation step for status transitions (e.g., marking done is irreversible).