ADR: a ship checklist the agent (and a rep) can actually finish

[YIKUAIBANZI]

Adds adrs/agent-ship-checklist.md.

The Agent tab can research forever. This proposes a small, versioned ship checklist of observed evidence gates (not model confidence) so a contact / company / deal can actually be marked ready — or blocked — in a way a rep can trust.

Happy to keep it as an ADR until you want the schema; I can implement the smallest slice (contact-only, three gates) if the idea fits.

---

Summary by cubic

Adds an ADR proposing a ship checklist that uses observed evidence gates instead of confidence scores, so the agent can mark a record ready or blocked in a way reps can trust.

^{Written for commit 3bfb56a. Summary will update on new commits.}

[vercel]

@YIKUAIBANZI is attempting to deploy a commit to the Comp AI - PoC Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Retargeted this onto main.

release is the default branch so that a plain clone runs the last tagged release, but nothing merges into it — it is fast-forwarded onto the tag by the Release workflow and that is all. Changes go to main, and reach release when a release is cut.

Nothing is wrong with your branch. If the diff now shows commits that are already on main, rebase and force-push:

git fetch origin main
git rebase origin/main
git push --force-with-lease

[cubic-dev-ai]

2 issues found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="adrs/agent-ship-checklist.md">

<violation number="1" location="adrs/agent-ship-checklist.md:5">
P2: When a human settles a gate, the checklist has no defined state for that decision. Define `waived` (including its human actor and rationale) as an explicit state, or specify how human settlement differs from agent-observed evidence.</violation>

<violation number="2" location="adrs/agent-ship-checklist.md:9">
P2: The contact checklist names four gates but the proposed smallest slice says `three gates`. Align the implementation scope with the gate list so the first slice has an unambiguous acceptance criterion.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The contact checklist names four gates but the proposed smallest slice says three gates. Align the implementation scope with the gate list so the first slice has an unambiguous acceptance criterion.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At adrs/agent-ship-checklist.md, line 9:

<comment>The contact checklist names four gates but the proposed smallest slice says `three gates`. Align the implementation scope with the gate list so the first slice has an unambiguous acceptance criterion.</comment>

<file context>
@@ -0,0 +1,9 @@
+
+Concrete gates I'd start with (contact): identity matched from a signature or LinkedIn URL already on the record; employer name observed (not inferred from email domain alone); at least one real thread or meeting on the ledger; next action has a why. Company and deal get their own short lists. Weak suggestions stay suggestions. Nothing about a person is guessed into a green check.
+
+What it breaks / does not do: it does not replace enrichment tools, the research budget, or the Agent tab transcript. It does not invent a knowledge base of prose (that's a different ADR). It adds a surface — and a stop condition — so the agent can stop and the rep can see why. Happy to keep this as an ADR until you want the schema; I can implement the smallest slice (contact-only, three gates) if the idea fits.
</file context>

[cubic-dev-ai]

P2: When a human settles a gate, the checklist has no defined state for that decision. Define waived (including its human actor and rationale) as an explicit state, or specify how human settlement differs from agent-observed evidence.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At adrs/agent-ship-checklist.md, line 5:

<comment>When a human settles a gate, the checklist has no defined state for that decision. Define `waived` (including its human actor and rationale) as an explicit state, or specify how human settlement differs from agent-observed evidence.</comment>

<file context>
@@ -0,0 +1,9 @@
+
+The agent can already research forever. What it cannot do is say, in a way a human can trust, that a contact or company is *done enough to act on*. I noticed this while watching an Agent tab keep scheduling rechecks: every pass found another weak signal, nothing was wrong, and nothing was ever "ready to call." The rep still had to invent the stopping rule in their head.
+
+What I want to change: give every contact / company / deal a small, versioned **ship checklist** — a list of *observed* evidence gates, not confidence scores. Each gate is either `observed` (with the tool / source that saw it), `missing`, or `blocked` (auth, empty mailbox, etc.). The agent may mark a gate observed only from a tool result already on the ledger. A human may settle a gate by hand. "Ready" means every required gate for that record type is observed or explicitly waived by a human — never because a model felt sure.
+
+Concrete gates I'd start with (contact): identity matched from a signature or LinkedIn URL already on the record; employer name observed (not inferred from email domain alone); at least one real thread or meeting on the ledger; next action has a why. Company and deal get their own short lists. Weak suggestions stay suggestions. Nothing about a person is guessed into a green check.
</file context>