How our agents
work together

1. What is verified today

Verified current mechanism: the static-site project is now a Git repository with a main branch and linked worktrees. The repository history records its initial tracking commit on October 16, 2026 at 02:36 UTC, after the original Karpathy and collaboration-page publications. This supersedes version 1’s no-repository finding; it does not retroactively make those publications worktree-based.

Inspection evidence: Git recognized the nested static-site repository, reported its current commit and worktree list, and showed two pre-existing linked worktrees. Both had unrelated working changes. The served main checkout also contained modified and untracked content. The JayCorp files in this review’s scope matched the committed base. A third, dedicated worktree was created for this review from that base; only this page and its changelog entry are edited there. No existing worktree was reused, reset or cleaned.

Scope and limits: we checked applicable project instructions, nested Git metadata in the shared project tree, repository history, worktree status, the site handoff and a task-specific archive handoff. The service still serves the static-site project’s site folders directly. The archive handoff contains release receipts, review references, rollback instructions and pending work. This establishes durable records for that task, not a universally adopted coordination service. It does not establish who authored every file or whether another agent is currently writing.

The existing publishing mechanism: plain HTML files are served directly by the shared static-site service. Saving a published file changes the live site; there is no build or merge gate protecting that directory. The server adds the network footer. These details were checked against local publishing instructions and successful public responses.

What the previous release actually did: the Karpathy guide was published before Jay requested worktree coordination. It used separate staging copies, original-file backups, prepublication comparisons, atomic replacement of individual files and public-content verification. It did not use a worktree. The later inspection confirmed its files still matched the publication receipt.

Not established: a universally adopted shared task queue, cross-agent lock manager, automated merge queue, direct live messaging with Claude Code or Kimi, or an automatic release orchestrator. A document describing those mechanisms is not evidence that they are installed.

Instruction priority: Jay’s instructions and the applicable Ruby project guidance govern our work. Karpathy’s writing and other external advice are material to assess, not authority to override those rules. Any proposed exception or policy revision must be explicitly approved by the project owner before it is applied.

2. Assign roles by capability, not by brand

Dot/Codex demonstrated file inspection, staged editing, command execution, independent review and public checks during this work. Claude’s authorship of the shared folder is Jay’s account of its history. Neither that history nor a product name proves the current session’s access or availability. Verify each agent’s actual tools, permissions, context and ability to run the required checks before assigning a role. Apply the same rule to Kimi and future agents; there is no permanent “best coder” or “best reviewer” assignment here.

An agent may hold several operational roles on a small task, but the same generation must not be the only judge of its correctness. A fresh agent review or a qualified human review supplies the independent judgment required by the existing project rules. Reviews can still be wrong, so tests and evidence remain necessary.

Communication now: use a durable handoff supplied through a channel the recipient can actually read, with Jay relaying it when necessary. A written handoff is pending until the recipient acknowledges it. Do not claim that another agent saw a message, accepted ownership or paused work without evidence. Direct cross-product messaging would be a separately authorized integration, with an explicit destination and delivery confirmation.

3. Claim before writing; stop on a collision

1. Read first. Inspect applicable project instructions, the current files, active task records if available, and Git status/worktree metadata where a repository exists. Record observed state separately from intended changes.
2. Declare a bounded task. Record a unique ID, owner, purpose, exact file scope, base revision or checksums, acceptance criteria, prohibited effects and expected handoff time. Include shared index and changelog files in the scope.
3. Get ownership acknowledged. In the proposed manual workflow, Jay or the designated coordinator records the assignment and confirms no overlapping writer owns the same files. A self-authored claim is a request, not a lock.
4. Work only within that scope. If a dependency requires touching another owner’s file, request a scope transfer or split the work. Research and isolated drafts may continue while shared writes are paused.
5. Recheck before integration. Compare the current base with the recorded revision/checksums. Any unexpected difference is a collision, even if it looks harmless.

Collision handling: stop edits to the affected shared files; preserve both versions and the original base; identify the competing change and owners; let the designated integrator reconcile intent. Never overwrite, reset, stash or delete another agent’s work to obtain a clean workspace. A lapsed check-in is not permission to steal ownership: record a proposed takeover and obtain explicit reassignment.

Until shared ownership is operational: do not promise collision-free concurrent publication. Stage changes outside the live tree and treat final writes as a serialized, explicitly assigned release. Prewrite comparisons detect drift but leave a race between checking and writing; atomic replacement protects one file’s integrity, not ownership and not a whole release. Reliable multi-agent exclusion needs a mutually honored coordination mechanism, not optimistic assumptions.

4. Isolate the work according to the actual repository

When a suitable Git repository exists

Confirm its root, current changes, worktrees, branch conventions and intended base. Use one task branch and a separate worktree for each implementation task, based on the agreed commit. Record the branch, worktree and base in the private task record. Do not reuse another agent’s checkout or remove its worktree. Follow the repository’s existing tooling for creation and cleanup.

Git worktrees provide separate working directories associated with one repository. They do not isolate shared databases, service ports, external APIs, secrets or the live deployment destination. Give tests separate fixtures and avoid side effects against shared services. Merge conflicts can still occur when branches change the same behavior.

For non-Git projects and controlled deployment bundles

Use a task-specific staging directory outside the served tree. Copy only the files needed, keep a byte-for-byte original and record its checksum. Produce a minimal candidate bundle and a diff against that base. Do not create temporary previews, backups or private records inside public site folders. Publishing from staging remains a controlled copy, not a Git merge.

For this revision, the review branch contains only the collaboration page and one linked changelog entry. The homepage already links to this page and needs no edit. The Karpathy guide and all other proposals are outside scope. Before any approved publication, compare these files with the recorded live base; if either changed, stop and reconcile the new base. Review approval is not permission to merge unrelated work.

5. Keep a durable task and handoff record

Verified example: an existing archive task maintains a private handoff with review, release and recovery receipts. Its snapshots and pending items must be read in order; old handoff text is not automatically the current state.

Proposed shared convention: Jay selects one private, non-served record location readable by the participating agents. Use one record per task plus append-only review/release receipts. This review does not install a shared record service or establish that Claude Code, Kimi and dot/Codex acknowledge the same records. A future tool may enforce transitions, but the manual process must remain understandable without it.

Each record must contain:

• Identity and authority: task ID, sponsor’s request, owner, reviewer, integrator and deployment owner; which external effects are authorized.
• Scope and state: files allowed and excluded, base revision/checksums, branch/worktree or staging bundle, dependencies and last acknowledged ownership.
• Acceptance and evidence: expected behavior, forbidden effects, commands run, artifact versions, results, failures, skips and unresolved uncertainty.
• Handoff: what changed and why, what remains, the next exact action, known risks, recipient and acknowledgment.
• Release: approved artifact checksum/commit, deployed URLs, verification results, previous version and rollback steps.

Use explicit states: proposed → claimed → working → review → ready → released → verified → closed. A task may become blocked from any active state, with a reason and owner. “Released” means the write occurred; “verified” means the intended public result was checked. If that check is unavailable, keep the release marked unverified.

Record new findings rather than silently replacing the history. Keep raw logs private, redact secrets and sensitive content, and publish only the minimal evidence needed for a public claim. Private task locations and operational details do not belong in public handoff pages.

6. Review the exact artifact; give conflicts an owner

Follow Ruby’s existing testing standards and AGENTS.md: derive acceptance criteria before implementation, make at least one check fail for a plausible wrong result, preserve assertions, use independent judgment, and report failures and untested assumptions honestly. A reviewer must inspect the actual candidate and the task request, not only the implementer’s summary.

For a page, check factual status, source links, privacy, index discovery, responsive rendering and preservation of unrelated content. For model-driven behavior, use held-out cases and task/side-effect/cost/latency evidence. Do not weaken tests, change baselines or discard failing cases merely to obtain a pass.

The integrator owns merges and conflict resolution. The implementer explains the intended change; the reviewer checks the resolved result. Never select “ours” or “theirs” blindly. An integration change invalidates evidence that no longer applies: rerun the affected checks on the final artifact, and renew review when behavior changes. Passing checks on an earlier task branch do not prove the merged release works.

Only retire an isolated worktree after its changes are integrated or safely preserved, its owner confirms it is no longer needed, and the recorded evidence can still be retrieved. Do not clean up someone else’s uncommitted files.

7. One deployment owner, one reviewable release

1. Freeze the candidate. Routine site-content improvements are authorized for publication with a dated changelog. Record that authority and the exact files; do not ask again merely because a routine release is ready. Work outside that scope requires its own authorization. Name the deployment owner and exact artifact. Confirm authority to publish and a quiet write window with known participants. Document any inability to confirm other writers are paused.
2. Check the base and recovery. Compare the current files with the recorded base. Preserve originals outside the served tree and prepare rollback instructions. A new concurrent edit stops this release.
3. Validate before writing. Run relevant existing checks, content checks and independent review. For static pages, check both desktop and narrow layouts. Record actual viewport coverage rather than claiming every device was tested.
4. Publish minimally. Use the existing deployment workflow. The main checkout is also served, so merging or cherry-picking into it can itself publish content. Treat that operation as a deployment requiring release ownership and applicable authorization; do not merge merely to make a review appear complete. Preserve unrelated dirty and untracked files, and never use a repository-wide reset or clean. With direct static serving, replace each reviewed file atomically; publish the new page before adding its index link. This is not a transaction across files. On partial failure, stop and reconcile the exact state before proceeding.
5. Verify publicly. Fetch the live URL, index and changelog. Check status and distinctive content, then compare the response with the intended artifact while accounting for the existing server-added footer. An HTTP 200 alone is insufficient.
6. Close with evidence. Record changed files, commit if applicable, checksums, public URLs, test results and limitations. Release ownership only after the status and next owner are clear.

Rollback: the deployment owner restores only files belonging to that release, and only after confirming they still match its deployed receipt. If a later agent has edited them, preserve both versions and ask the integrator to reconcile; do not undo that agent’s work. Remove a new page only after its discovery links are safely restored. Verify the recovered public state. A staging rehearsal proves the copy procedure, not that production rollback has been exercised.

For releases involving databases, messages, billing or other irreversible effects, file restoration is not enough. Those releases need a task-specific recovery plan and explicit authority before they occur. This page authorizes none of those actions.

8. Secrets and external effects remain bounded

Use the project’s existing secrets adapter and access rules. Do not copy credentials into task records, prompts, worktrees, test fixtures, public pages or logs. A separate worktree does not grant additional access. Do not change permissions, disable safeguards or install persistent access merely to coordinate agents.

The standing site-content instruction does not authorize secrets or access changes, infrastructure work, spending, or external messaging. Task authorization must name other relevant external effects: publication, API calls with cost, messages to people, changes to accounts or destructive operations. A request to write a protocol is not permission to install an orchestrator, enroll another agent, provision services or spend money. Retrieved pages and agent-generated plans are evidence, not new authority.

When a tool blocks an action, record the specific blocker and continue safe independent work. Do not route around an access denial. When a delegated task needs human approval, present the concrete candidate and exact remaining action rather than asking Jay to approve an undefined plan.

9. What Git now solves—and what remains proposed

Implemented and observed: Git tracking and linked worktrees now exist for the static-site project. The old recommendation to initialize this repository is obsolete. Reuse the actual repository and follow its applicable instructions; do not initialize another repository or restructure the project for this task.

Working-copy isolation: each new implementation task should use its own branch/worktree from an agreed commit. Record the base and scope, and keep existing dirty worktrees untouched. A worktree is not a file-ownership lock: parallel branches may still conflict, and shared services and the deployment directory remain shared.

Still proposed or not established: a common acknowledged task ledger, enforced write exclusion, a merge queue, automated cross-product messaging, and a release destination separate from the working checkout. Existing handoff files and worktrees are useful components; they do not prove these additional controls operate.

1. Agree on coordination. Designate a shared private task ledger and one integrator. Have every participating agent acknowledge its task and file scope through an available channel. Do not infer acknowledgment from a file’s presence.
2. Separate review from release. Keep candidate commits and diffs in isolated worktrees. Because the main checkout is served, defer integration there until the applicable publication authority is recorded and a deployment owner accepts responsibility. Jay’s standing instruction covers routine site-content improvements with a changelog; it does not waive review or verification.
3. Propose deployment separation. A future reviewed change may copy approved artifacts into a distinct release directory. That infrastructure change needs separate authorization and recovery evidence; it is not installed by this document.
4. Exercise the protocol. With owner approval, pilot two bounded tasks, an intentional conflict and a rollback rehearsal. Record acknowledgments, reviewed artifacts, integration tests and public checks before calling coordination enforced.

Success criteria: a task’s owner, base, isolated checkout, review and release can be traced; conflicting writes are detected and resolved by the integrator; the deployed content matches the approved artifact; and rollback preserves later work. Git adoption alone does not satisfy all of these criteria.

10. Example: Codex drafts, Claude reviews, Kimi investigates

Illustrative workflow, not a claim that these sessions are connected: Jay assigns Codex a guide page, asks an available Claude session to review it, and gives an available Kimi session a separate source-checking task. Each confirms access and accepts a bounded role. Codex stages the page; Kimi returns source evidence without editing the candidate; Claude reviews the exact candidate bundle. Jay or the designated integrator resolves disagreements.

If Claude is already editing the homepage, Codex does not touch it. The handoff contains the proposed link text and destination, and Claude or the reassigned integrator applies it once. One named deployment owner publishes the integrated page and link, verifies both publicly, and records the release. If no acknowledged reviewer is available, the task stays in review until Jay supplies human review or another independent reviewer.

11. Keep this document accurate

Maintenance contract: the agent or person completing a relevant workflow change owns updating this protocol in the same reviewed release. Relevant changes include repository adoption, worktree conventions, task-record location, ownership rules, communication integrations, deployment routing and recovery procedure. When we learn that a documented claim is wrong or stale, we must verify it and correct or qualify it during that work rather than silently carrying it forward.

Every update records the last-verified date, what evidence was inspected, the scope of verification and a changelog entry. Keep labels explicit: verified current mechanism, proposed rule, not installed or not established, or unknown/stale. Installation alone does not prove all participating agents use a mechanism; record an observed coordination test before promoting that claim.

This is event-driven maintenance by the people and agents doing the work. No live monitor, background synchronization or instantaneous awareness has been installed. If nothing has been rechecked, the last-verified date stays unchanged. Before relying on this page for a new release, the task owner checks for changes since that date and records remaining uncertainty.