Docs / Team

Hydrate Team

Shared project memory for your whole team, backed by a plain git repo. No new infrastructure. No central server. No auth service. Just a private GitHub / GitLab / internal Gitea repo the team already trusts for code.

The repo is yours. Hydrate is a git client, not a sync service. Your team's canon, per-teammate fact JSONL, and manifest live in a repository you (or your organisation) host and control - we never see the contents. Sedasoft is therefore not a data processor for your team's memory under Article 4(8) of the UK GDPR / EU GDPR. Full details on /privacy →

The model in one paragraph

Each teammate installs Hydrate locally. The team shares one git repo - private by default - that holds a manifest.yaml (who's on the team), canon/ (hand-authored architectural rules, version-controlled), facts/ (per-teammate per-day append-only JSONL streams of captured facts), and prune/ (a rejection list the manager maintains). Teammates push their local facts; teammates pull the combined stream. The senior dev pins the architecture in canon; every teammate's Claude Code session inherits it.

Why git, not a server

Zero new infrastructure. Every team that needs Hydrate Team already has a git host.
Audit trail for free. Every fact is a commit - blameable, revertible, optionally signed.
Conflicts your devs already understand. Two people pin contradictory canon → normal canon.md merge in a PR, not a custom UI we invent.
Air-gap-friendly. Enterprise teams can use a bare repo on an internal Tailscale mesh; Hydrate never reaches the public internet.

Quick start

1. Manager creates the team

# On the lead dev's machine:
hydrate team init \
  --team-id=acme-eng \
  --display-name="ACME Engineering" \
  [email protected] \
  [email protected]:acme/hydrate-team.git

This creates ~/.hydrate/teams/acme-eng/ as a local git working copy, commits an initial manifest.yaml, and pushes to origin/main. The remote can be anything git clone-able - GitHub Enterprise, GitLab self-hosted, Gitea, Gerrit, a bare repo on an SMB share.

2. Pin initial canon

hydrate canon add --project=api-service \
  --text="Use stdlib flag for CLI args; no cobra." \
  --category=architecture
hydrate canon add --project=api-service \
  --text="Errors propagate via fmt.Errorf with %w." \
  --category=architecture
hydrate team push --team=acme-eng --project=api-service

3. Teammates join

# Each teammate, one-time:
hydrate team clone \
  [email protected]:acme/hydrate-team.git \
  [email protected]

# Daily:
hydrate team sync # pulls everyone's new facts + pushes yours

Daily use

Command	What it does
`hydrate team sync`	Pull + push. Most common.
`hydrate team status`	What's new on both sides
`hydrate team push`	Write-side only
`hydrate team pull`	Read-side only
`hydrate team members`	Who's on the team per manifest
`hydrate team members add --email=…`	Add a teammate. Edits `manifest.yaml`, commits, pushes.
`hydrate team members remove --email=…`	Remove a teammate. Also strips them from `manager_emails` if present.
`hydrate team members promote --email=…`	Grant manager. Adds to `members` first if they aren't already.
`hydrate team members demote --email=…`	Revoke manager. Refuses to demote the last remaining manager.
`hydrate team show --fact-id={id}`	Full provenance of one fact
`hydrate team prune --fact-id={id} --reason="..."`	Manager-only. Reject a captured fact; future pulls skip it.

The dashboard

localhost:49849/dashboard/team.html?team={team_id} - members, per-teammate contribution counts, conflict candidates (heuristic: same-category facts from two teammates), and a live facts table with Reject buttons (manager-only, enforced by the manifest's manager_emails list).

Repository layout

my-team-hydrate/
├── manifest.yaml # team membership + project map
├── canon/
│ └── {project-slug}/
│ └── canon.md # human-edited; normal PR-reviewable
├── facts/
│ └── {project-slug}/
│ ├── [email protected]/
│ │ ├── 2026-04-15.jsonl # append-only, never rewritten
│ │ └── 2026-04-20.jsonl
│ └── [email protected]/
│ └── 2026-04-19.jsonl
├── prune/
│ └── {project-slug}/
│ └── rejections.jsonl # fact IDs the manager has rejected
└── README.md # generated; explains the layout

Conflict resolution

Three distinct cases, all handled cleanly:

Same fact captured twice. Resolved at injection time by content-hash dedup. No git conflict - each teammate writes to their own JSONL file.
Contradictory facts ("we use ORMs" vs "we don't"). Both land in the team store; the manager runs either hydrate team prune to suppress the wrong one or hydrate canon add to elevate the right one to authoritative canon (overrides the soft team fact via channel authority).
Concurrent canon.md edits. Standard git merge conflict; resolved in a PR like any other code change. Hydrate doesn't try to be cleverer than git.

Manager role

The manager_emails list in manifest.yaml is the source of truth. Managers may prune, promote facts to canon, and edit membership. Enforcement is via git branch protection + CODEOWNERS on the team repo - not a permissions service Hydrate runs. A team that doesn't use branch protection gets the honour system; the audit trail still detects violations after the fact.

Pricing

Team features (shared memory across seats, team canon sync, aggregate dashboard, priority support) ship at $29 per user per month post-beta. Today, install Free or Pro on each teammate's machine - both lock the personal $5/mo rate forever. See /beta and /pricing.

What's not yet in v1

Real-time updates. Facts arrive on pull; no webhooks. (Deliberate - would require a server.)
Project-scoped membership. All teammates see all team projects today. Per-project ACLs are v2.
Cross-team federation. A consultant on three teams has three repos. Fine for v1.