Repository Continuity
The homepage stays simple. This page carries the full model: how Snipara keeps developers and AI agents synchronized by turning repository activity, PRs, decisions, and code impact into actionable, source-grounded context.
Product boundary
Repository continuity is not a PR review assistant, vector database, generic RAG layer, Snipara Sandbox, or orchestrator. Those surfaces can exist underneath the product, but the user value is operational repository context that survives tools, sessions, branches, and agents. Helvabase applies the same authority model to business workflows.
The repository continuity loop
Snipara observes repository movement, keeps the durable parts sourced, and turns them into three daily surfaces: a brief before work starts, a filtered view of what changed, and an Answer Pack during review. The same evidence can feed AI agents, but the authority stays attached to the repository.
Three daily surfaces
Repository continuity becomes useful when the same evidence is shaped differently before editing, while resuming, and during review.
Start Work Brief
A pre-edit briefing for the current task: likely files, recent PRs, relevant decisions, risky contracts, tests, and collision signals.
What Changed For Me
A return-to-work surface that filters repository movement down to the merges, decisions, stale assumptions, and overlaps that matter to your branch.
PR Answer Pack
A review artifact published back to GitHub so humans and AI agents start from the same repository truth during PR review.
Shared continuity core
Start Work, What Changed, and agent resume now share one render-ready continuity core. The same backend scope produces the same categories everywhere:
- Repository evidence: recent PR or MR movement, changed files, impacted symbols, overlaps.
- Reviewed memory: decisions and approved memory that should constrain the implementation.
- Runtime continuity: execution traces, checkpoints, and resumable session context.
- Freshness and authority: source quality, stale warnings, and fallback state.
- Next actions: typed continuity actions rendered from the same scope contract instead of ad hoc strings.
The important product boundary is that runtime continuity is not the same thing as durable reviewed memory. Execution traces help you resume safely. Reviewed decisions tell you what must stay true.
Issue-aware continuity
When PR evidence deterministically links to Jira or Linear issues, Start Work, What Changed, Team Sync, and resume can surface issue summaries, blocked-state warnings, related PR counts, and caveats. That work intent stays read-only and advisory. Snipara does not become the planning system or work-item authority, and the repository review pack remains the operational source of truth.
Operational context graph
Snipara also ships a separate operational context graph for continuity, authority, and lineage across repository evidence, reviewed memory, runtime continuity, tasks, agents, and linked external work items. It is additive. It does not replace GitHub or GitLab review evidence, and it does not replace the specialized code graph. The first consumer is What Changed For Me, where graph cues enrich resume context while direct repository evidence remains primary.
Core primitives
Start Work Brief
Before a developer or agent opens the editor, show the files, PRs, decisions, pitfalls, tests, and overlap risk that matter for the task.
snipara-companion team-sync start-work --summary "add team invite permissions" returns likely files, recent related PRs, relevant decisions, suggested tests, and collision risk.
What Changed For Me
Turn repository activity into a return-to-work ritual instead of a raw changelog.
Filter by current branch, recent files, touched symbols, issues, PRs, and previous work sessions.
PR Answer Packs
Attach a compact, sourced context artifact to a pull request so humans and AI agents start review from the same repository truth.
Include what changed, impacted symbols, related decisions, risky contracts, stale warnings, tests to run, reviewers, and source links.
Decision Ledger
Promote durable rules from PR discussions and reviews only when they should survive the thread.
Personal API keys remain valid for invited workspace users, sourced to PR #214, dated, reviewed, and revocable.
Context Authority
Make every context claim inspectable before it is handed to an AI client or reviewer.
Attach source_type, source_url, commit_sha, collected_at, freshness, confidence, validated_by, and stale_reason.
Overlap Risk
Show concurrent work before it becomes a merge surprise.
Medium collision risk: billing/checkout also touched in PR #182; stale assumption warning on plan checks.
Start Work Brief example
The brief is the main daily ritual. It answers: what changed before I start coding, what matters for this task, and what could conflict with my branch. It is a named artifact, not a generic search result.
In the current product, the same hosted evidence now backs snipara-companion team-sync start-work, snipara-companion team-sync what-changed, resume handoffs, and the Team Sync review sections inside PR Answer Packs.
Agents can also fetch that continuity directly through hosted MCP with snipara_resume_context when they want one compact bundle instead of stitching Start Work, What Changed, decisions, and execution-memory together client-side.
Reviewed decisions or durable rules that constrain the task.
Source URLs, commit SHA, collected time, and stale warnings.
Paths, symbols, or modules that are likely to matter first.
Collision risk, concurrent PRs, outdated plans, and caveats.
Focused checks that should prove the task-specific surface.
Memory IDs, answer-pack refs, and docs to read before editing.
A compact instruction for the next agent or reviewer.
Context authority contract
Context is only useful when a reviewer or agent can judge whether it is safe to use. Answer Packs, briefs, and decisions should carry evidence metadata whenever the source supports it.
This contract is not code-only. The same fields can label active client truth, historical reference material, and company-wide reusable context so business AI workflows do not flatten precedent into current fact.
| Field | Meaning |
|---|---|
| source_type | Where the context came from: PR, commit, issue, review, decision, file, or manual note. |
| source_url | The GitHub or Snipara URL a human can open before trusting the claim. |
| commit_sha | The repository state used when the context was collected or validated. |
| collected_at | When Snipara observed the context. |
| freshness | Whether the context is fresh, aging, stale, or superseded. |
| confidence | How strongly Snipara can support the claim from available evidence. |
| validated_by | Human, workflow, check, or agent that reviewed the context. |
| stale_reason | Why the context should be treated carefully or refreshed. |
Where the deeper machinery lives
Runtime execution, orchestrator proof gates, symbol-aware retrieval, MCP tools, workflow modes, and package-level commands are developer infrastructure. They should be discoverable in docs, not forced into the first marketing fold.
PR Answer Packs
GitHub-native context artifacts for pull requests.
Context Authority
The trust layer behind source, freshness, confidence, and stale warnings.
Team Sync
Shared briefs, handoffs, merge readiness, and proof gates.
GitHub Sync
Repository, PR, issue, review, and Marketplace event ingestion.
Workflow Modes
LITE, STANDARD, FULL, and orchestrated agent workflows.
snipara-companion
Local start-work, handoff, resume, what-changed, and workflow helpers.
Snipara Orchestrator
Enterprise proof gates, htasks, drift checks, and explicit multi-agent coordination.
Snipara Sandbox
Repeatable execution and validation when repository context needs proof.
MCP Tools
Hosted MCP tools for recall, context query, code graph, planning, and memory.