Teams

Teams share normalized sessions selected by canonical repository or repository owner. The selector chooses whole sessions, not individual messages or files.

A matched session can contain out-of-scope data

Team uploads include full transcripts, tool calls and results, metadata, attachments, and captured artifacts. Message and tool content can mention or contain files from outside the selected repository. Attachments and artifacts are shared as bytes and are not content-redacted. Anyone with destination read access can read uploaded data.

Included and excluded data

New Team uploads include:

• normalized transcript, event, metadata, conversation, and viewer records for each matched session;
• complete message and tool-call/result text from those records; and
• attachment and captured-artifact sidecars.

They exclude:

• session .raw/ provider backups;
• shared provider databases under raw-sources/;
• byte-preserved web exports under raw/;
• the memory archive; and
• device-local Deep Recall research threads.

Hansard removes structural local filesystem paths from shared metadata, manifests, transcript metadata, viewer summaries, artifact records, and conversation frontmatter. It does not rewrite ordinary message text, tool arguments, tool results, attachments, or artifact bytes. Pattern redaction can reduce exposure in normalized text but is not semantic review.

Portable scope

A shared Team policy accepts canonical repository and repository-owner selectors. Repositories and owners can be combined; a session matching any supplied value uploads.

Machine-local paths, folders or containers, providers, devices, and local scope overrides are rejected. This keeps one signed selector meaningful on every member’s machine, but it does not inspect each message for repository scope.

Signed policy and verified invites

Each Team has a signed schema-3 team.json containing its identity, current revision, selector, cadence, and manager public keys.

• Creation generates a local Ed25519 manager key and signs revision 1.
• A Team invite pins the Team ID, revision and policy hash, manager fingerprint, and storage locator.
• An invite contains no storage credentials or private key. Send credentials separately through an appropriate secret-sharing channel.
• Bucket credentials alone do not establish membership or authorize a policy change.
• Unknown signers, tampering, rollback, forks, and revision gaps fail closed.
• Only a device holding a current manager key can sign a shared-policy change. Other members can change only their local connection and sync direction.

Upload consent is separate from signature verification. Hansard binds accepted consent to the exact destination, prefix, non-secret account identifier, Team identity, namespace version, and selector. A valid policy, destination, account, or scope change pauses scheduled uploads until the new preview is explicitly accepted.

Create or join in the app

Open Settings → Teams. To join, choose Join with an invite, paste the manager-issued invitation, add this device’s storage credentials when needed, and review the verified Team identity, policy revision, manager fingerprint, and storage location before Connect to team. The invitation and bucket credentials are deliberately separate inputs.

To create a Team, choose Create a new team, select its storage type, and build Conversations shared from repository and owner rules. Each row is an OR rule: a conversation matching any row uploads whole. Set the upload and receive schedules, review the full-transcript warning, then select Create team and upload. The resulting Verified invitation can be copied from the page and sent separately from storage credentials. Existing connections appear under Your team connections, where trust, scope, cadence, and local connection state remain visible.

Create and join a Team

1. Choose a fresh bucket or prefix.

   A shared-folder Team is useful for a local test:

   hansard team create \
     --name "Example Team" \
     --endpoint file:///srv/hansard-team \
     --repos github.com/example-org/example-repo

   An R2-backed Team can combine repositories and owners:

   hansard team create \
     --name "Example Team" \
     --target r2 \
     --endpoint https://ACCOUNT_ID.r2.cloudflarestorage.com \
     --bucket example-team-hansard \
     --repos github.com/example-org/example-repo \
     --owners another-example-org \
     --upload-interval 5 \
     --receive-interval 5

   Creation previews the matched-session count, displays the sharing disclaimer, writes signed policy, and performs the first scoped upload only after confirmation. Non-interactive creation requires --yes.

2. Generate an invite.

   hansard team invite example-team

   Generate a fresh invite after later policy revisions so it pins the current revision and hash.

3. Join from another installation.

   hansard team join --invite 'hansard-team-invite-v1.…'

   Supply cloud credentials separately when the Team uses R2, S3, or another compatible service. Join verifies the invite and signed policy, previews the upload boundary, and records the connection after confirmation. Run hansard sync when ready to exchange archive objects.

4. Inspect the current trust and sync state.

   hansard team status
   hansard sync status

Received teammate sessions appear read-only with person and device attribution. Current uploads use collision-resistant member and device namespaces under:

<prefix>/members/member--<id16>/devices/device--<id16>/...

Display renames keep these keys. Local replicas live under received/teams/<team-id>/members/<member-id>/devices/<device-id>/. Each Team has separate files, catalog identities, and pruning scope, including when the same source conversation is shared with multiple Teams. Multiple historical name aliases for the same stable replica cause receive to stop before writing; publish into a fresh Team destination instead of combining ambiguous revisions.

Existing and legacy Team destinations

Use a fresh bucket or prefix for the current Teams boundary. An older destination can retain personal or out-of-scope normalized sessions, prior namespace formats, snapshots, unidentified raw keys, object versions, retention copies, replication, or provider backups.

Preview the narrow legacy-raw cleanup when retiring an older Team:

hansard team purge-legacy-raw example-team --dry-run

An explicit --yes run removes only identifiable current raw object keys and legacy raw files from all local Team mirrors on that machine. It is not a complete erasure or migration tool and does not remove normalized sessions, ambiguous namespaces, snapshots as a whole, object versions, or provider backups. Complete retention cleanup in the storage provider.

Use Personal Sync instead when every device belongs to one person and the complete archive, including raw backups and memories, should be backed up.