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.
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.
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.