feat(100x-continuity): a factory that builds a team's session handoff

[tisu-ai]

What this is

100x-continuity is a factory. It is not a handoff plugin — it is the thing that writes
one.

An Operator installs it in Claude Code, answers questions about their team and their
storage, and it emits a Kit: one tailored plugin, with the store baked in, written
into their plugin repo with its marketplace row. Their Teammates install the Kit and
use it in Cowork. They never see this.

That one fact explains the layout. skills/ holds set-up-handoff, verify and
store-service — none of them hand anything over. The skills a person actually talks to,
hand-off and pick-up, live under templates/kit/ and exist only inside emitted Kits.
CONTEXT.md is the glossary: Factory, Kit, Emit, Plan, Operator, Teammate, Handle,
Bundle, Store, Registered name, Route, Unreachable.

How setting one up goes

flowchart TD
    A["Operator: build my team a handoff plugin"] --> B[set-up-handoff]
    B --> C{Is a Kit already in this repo?}
    C -->|Yes| D[Read kit.json. Use it for the defaults.]
    C -->|No| E[Read the repo. Find the synced folders.]
    D --> F[Ask: the name, the repo, who it is for]
    E --> F
    F --> G{Where do handoffs go?}
    G -->|A folder the drive syncs| H[Ask for the folder and the group]
    G -->|A store service| I["Ask the name it will be registered under,
    how Teammates reach it, and where its source will live"]
    H --> K[Write continuity-plan.md]
    I --> K
    K --> L{Does the Operator approve the Plan?}
    L -->|No| F
    L -->|Yes| M["Write the Kit, its marketplace row,
    and the Operator's notes into the repo's CLAUDE.md"]
    M --> N{Did the Plan choose a service?}
    N -->|No| V[verify]
    N -->|Yes| S[store-service]
    S --> S1["Copy the server template out,
    to a directory outside the plugin repo"]
    S1 --> S2[Ask which storage vendor. Get credentials.]
    S2 --> S3[Run it from the Operator's own .env and check it answers]
    S3 --> V
    V --> O[Run the contract test. Hand a session over. Open it again.]
    O --> P["Report: proven / proven against a stand-in / not proven yet"]

Loading

One entry point, and Plan and Emit are phases rather than skills. A chain split across
skills has a step nobody starts, and the step that gets skipped is always the last one —
docs/adr/0001-one-setup-skill.md records that decision. verify stays separately
invokable because "a Teammate says pick-up is broken" must not re-interview anyone.

Four decisions worth reviewing

The registered name is chosen at Plan time. The Operator picks it before anything is
written, and builds the server to answer to it afterwards. Asking for the name once a
server exists is how a Kit and a server end up never meeting — a failure nothing reports,
which surfaces as tools that are simply absent.

The store server lives outside the plugin repo. A plugin marketplace is a git clone:
installing one plugin copies the whole repository to every Teammate's machine. Server
source inside it is server source on every laptop, and one bad .gitignore day is a
credential on every laptop. kit.json never records where the server lives — it ships to
every Teammate. The Operator's own CLAUDE.md records it instead.

Emitting is a script, not a copy-and-substitute done by hand. A skill filling twenty
files does it slightly differently every run, and the difference surfaces in a Teammate's
session weeks later. scripts/emit.py owns five rules: placeholders are all-or-nothing, a
Kit describes one store, the marketplace source is repo-root relative, a non-empty
directory with no kit.json is refused, and only the text between its own markers in
CLAUDE.md is rewritten. Those markers carry the Kit's name, because one repo can ship
two Kits.

A Kit checks its store is reachable before it packages anything. No matching tool, or
a folder root that is not on this machine, means nothing was sent — and the skill says
that and stops rather than filing the work where nobody is looking.

Where handoffs go

Store	What it is	Who can read a handoff
Folder	a directory a sync client already watches	anyone who can open the folder reads every handoff in it
Service	object storage behind an MCP server the Operator runs	only the people the sender shared it with

There is deliberately no s3 kind. This engine addresses a store it can list, read back
and verify; a presigned PUT can do none of those, so config.check_store_kind rejects
s3 and minio by name and points at the service store.

A publication is one immutable bundle plus a marker written last. The manifest describes
content and nothing else — no timestamp, no source path, no store — so the same
conversation and files pack to identical bytes and an unchanged republish is recognised
rather than filed twice.

What travels

Travels: the conversation, a readable Digest of it, and the artifacts named at
handoff.

Removed on the way: credential-shaped values. Artifacts are scanned and refused, never
rewritten — they are files a person composed, so a credential-shaped value inside one
stops the publish by name.

Never read: the host's audit log and its session metadata. A handoff is a record of
the conversation, not of the machine it ran on.

Redaction matches shapes. It does not catch a secret written out in prose. Nothing here
describes a handoff as safe or clean.

Two test layers, and only one gates anything

templates/kit/tests/contract_test.py ships inside every Kit: deterministic, no model, no
money, driven from a synthetic session in a throwaway HOME. It branches on kit.json and
skips the half its store does not have. CI emits a Kit of each store kind and route and
runs it.

The Kit's evals/ are claude plugin eval cases about what the model does with the two
skills. They cost money, gate nothing, and exist for the failures a contract test
structurally cannot see — a skill that fires on the wrong words, or one that improvises
when the store cannot be reached.

Checking it locally

cd plugins/100x-continuity
PYTHONPATH=scripts python3 -m unittest discover -s tests -p 'test_*.py'   # 360 tests

python3 plugins/100xeval/skills/100xeval/scripts/run.py eval --static-only  # all plugins 1.00
python3 scripts/check_docs.py

Python 3.11 is the floor and macOS ships 3.9, so uv run --python 3.11 --no-project python
runs the suites on the real floor.

Review note

These files need author ≠ reviewer:

• plugins/100x-continuity/scripts/engine/redact.py — the only thing between a full
  session transcript and a folder that syncs to somebody's cloud account.
• plugins/100x-continuity/scripts/engine/bundle.py — what refuses a hostile archive
  before it is unpacked onto a reader's disk, and what refuses to publish a staged file
  holding a credential.
• plugins/100x-continuity/templates/store-service/server.py — the template that decides
  who can read whose session, on infrastructure the Operator runs. principal() fails
  closed without a verified identity.
• .github/workflows/ci.yml — gains a matrix row for the second suite and a step that
  emits a Kit and runs its contract test.

No guard is relaxed anywhere in this branch. The CI change is added coverage only.

redact.py's patterns look like 100xeval's SECRET_PATTERNS and must not be merged with
them: the linter optimises for precision, because a false positive costs a plugin its
security sub-score; the redactor optimises for recall, because redacting a placeholder
costs nothing and missing a credential costs everything.

Rebased onto the squashed main

The previous branch is gone, so this one starts from init: 100xtools. It carries only the
continuity work — plugins/100xeval/ is taken from main verbatim, including the
--comment scorecard this branch predates.