PT 4: Ship SwapMeet with Agent Clones

Use three Claude Code clones and one GitHub issue to ship a SwapMeet change.

Introduction

30 Second Summary

Product changes get messy when several people work at once. A missing shared record leaves everyone guessing about ownership.

In this project, you will use SwapMeet's vendor-agnostic harness to ship the marketplace MVP through three isolated repository clones with Claude Code. The harness constitution, Agent Skills, and coordination tools will direct one coordinator plus two developer lanes through a single GitHub issue.

What You'll Build

Picture browsing local finds, filtering by category, opening an item, and posting a new listing that remains available after the page reloads.

By the end of this project, you'll have:

A reusable agent harness where AGENTS.md defines the rules and five project skills provide repeatable workflows.
A three-clone factory where one coordinator directs isolated frontend and backend lanes through a shared issue.
A working marketplace MVP where you can browse listings, filter categories, open item details, and post a listing that persists in data/listings.json.
Secret Mission: Introduce one controlled contract amendment after both lanes become active using only the issue protocol.

Are there any prerequisites?

You need the author-provided SwapMeet repository plus its design archive. Your GitHub fork must have Issues enabled.

This project assumes the confirmed learner environment: macOS 13.0 or later, Apple Terminal, Git, GitHub CLI, GitHub access, plus authenticated Claude Code.

Before We Start

Before the factory starts, this checkpoint locks in the rule that lets three isolated agents work toward one result. The GitHub issue is the only communication channel, with no cross-window chat, shared local memory, or unlogged decisions.

Stand Up the Three-Clone Factory

Your factory protocol is set. One GitHub issue remains the only communication channel for every role.

Parallel Claude Code sessions need separate Git working directories. Independent full clones prevent local edits or session memory from leaking between roles.

In this step, get ready to:

Create independent full clones named 3-prime-swapmeet, 1-prime-swapmeet, and 2-prime-swapmeet.
Start a separate Claude Code session from each clone.
Pass the repository preflight in all three clones.

Meet the repository artifacts

The repository already contains the operating system and product brief for your three-clone factory. You will use these files directly instead of recreating the workflow or inventing the build scope.

AGENTS.md is the constitution for identity, scope ownership, contracts, evidence, commits, and destructive actions.
CLAUDE.md imports the constitution and explains how Claude Code discovers the shared skills.
The product requirements define the marketplace MVP, the real frontend loop, the mocked experiences, and the five backend endpoints.
The design system supplies the tokens, Day and Night themes, icons, and reusable React components.
The canonical skills directory contains the planning, issue, lane, coordinator, and protocol workflows.
The harness guide maps every tool to its purpose and explains the three clone roles.
The Claude Code settings connect the force-push guard before Bash tool calls.

Create the independent clones

Each lane needs a complete repository checkout with its own working tree. The repository setup tool creates the three required clone directories from your fork.

Return to the Apple Terminal window from earlier.
Move into the local SwapMeet checkout connected to your fork by using cd with its full path.
Create all three full clones by running the repository setup tool:

harness/tools/clone-setup.sh

What does this command do?

The setup tool creates 3-prime-swapmeet, 1-prime-swapmeet, and 2-prime-swapmeet as full clones of your fork.

Each clone receives an independent working directory and a matching Git identity. Commits can now show which factory clone authored them.

After the command finishes, you should be able to identify three separate clone paths ending in 3-prime-swapmeet, 1-prime-swapmeet, and 2-prime-swapmeet.

Did the clone setup stop?

Confirm your Terminal prompt is inside the SwapMeet checkout that contains harness/tools/clone-setup.sh.
Confirm the local checkout is connected to your GitHub fork.
Read the final setup message before retrying because it identifies the failed repository check.

Help me diagnose why the SwapMeet clone setup tool did not create all three full clones.

Launch one session per clone

A Claude Code session takes its project context from the directory where it starts. Launching one session from each clone keeps the three roles isolated.

Press Command-N twice in Apple Terminal to create two additional windows.

The separation is now visible. You have one Terminal window for every factory role.

Move one Terminal window into each clone path by using cd with the corresponding full path from the setup output.

Your three prompts should now show directories ending in 3-prime-swapmeet, 1-prime-swapmeet, and 2-prime-swapmeet.

Start Claude Code in all three prepared Terminal windows by running this command in each window:

claude

Why start from each clone?

The claude command starts an interactive session in the current project directory. Each prompt displays the working directory so you can verify which clone that session controls.

Separate starting directories give every role its own repository context. This is the boundary that prevents shared local memory.

You should now see three independent Claude Code sessions. Each session prompt should display a different SwapMeet clone directory.

Verify the loaded repository instructions in each Claude Code session by running this slash command:

/context

In each session, inspect Memory files. You should see CLAUDE.md loading the repository constitution from AGENTS.md.

Project instructions missing?

If the repository files are missing, confirm the session started inside one of the three SwapMeet clones. Restart the session from that clone before assigning a role.

Help me restore the SwapMeet project context.

Tell the Claude Code session rooted at 3-prime-swapmeet that it owns the coordinator role.
Ask that session to repeat its current clone directory plus its assigned role.

The session should identify 3-prime-swapmeet as its directory. It should acknowledge the coordinator role.

Tell the Claude Code session rooted at 1-prime-swapmeet that it owns the frontend lane role.
Ask that session to repeat its current clone directory plus its assigned role.

The session should identify 1-prime-swapmeet as its directory. It should acknowledge the frontend lane role.

Tell the Claude Code session rooted at 2-prime-swapmeet that it owns the backend or data lane role.
Ask that session to repeat its current clone directory plus its assigned role.

The session should identify 2-prime-swapmeet as its directory. It should acknowledge the backend or data lane role.

Your factory now has three separate rooms. Every role knows its own clone without receiving another role's local context.

Does a session show the wrong clone?

Close the Claude Code session that shows the incorrect directory.
Return that Terminal window to the intended clone with cd.
Restart Claude Code from the corrected clone directory.

Help me correct a Claude Code session that started from the wrong SwapMeet clone.

Pass preflight in every clone

Isolation only helps when every lane can reach the same fork and satisfy the harness prerequisites. The preflight checks Git, Node.js 20 or later, GitHub CLI authentication, and repository resolution.

Claude Code may request permission after you submit the repository command. The request should reference the clone shown in that session.

Before you run the final check, do you expect all three clones to pass the same checks while reporting different directories?

Run the repository preflight in every Claude Code window with this command:

harness/tools/preflight.sh

What does preflight prove?

The Git check proves the command-line tool is available.
The Node.js check proves the installed major version is 20 or later.
The GitHub CLI checks prove the lane is authenticated and can resolve the current repository.

Confirm the displayed clone path if Claude Code requests permission.
Approve the repository script run if prompted.

Each window should report successful GitHub CLI authentication. It should also pass expected-repository identification, Node.js, and the repository runtime checks.

That is the factory floor ready. Every lane now has its own clone, role, and passing harness.

Did a preflight check fail?

Stop this step in every window that reports a failed check.
Confirm the failing session shows the intended clone directory.
Use the reported check name to repair authentication or the missing runtime requirement before retrying.

Help me diagnose a failed SwapMeet preflight check from its output.

Your three isolated lanes are ready. Next, the coordinator will turn the product requirements and design system into one issue with fixed ownership, contracts, and acceptance evidence.

Plan the Seams and File the Issue

Your three Claude Code windows are ready. Each clone has its own working directory.

Safe parallel work now depends on boundaries that every lane can verify. One GitHub issue must fix file ownership before any code is written.

It must also fix the data or API contract. It must define the evidence that proves each lane is complete.

In this step, get ready to:

Define exact ownership for two lanes through repository inspection.
Turn the approved plan into one authoritative issue.
Have the coordinator generate one gated bootstrap prompt for each worker.

Define ownership and contracts

Agent Skills package reusable workflows for Claude Code. The implementation-plan skill turns the product requirements and design system into owned files, contracts, acceptance checks, and risks before either lane writes code.

Switch to the Claude Code window rooted at 3-prime-swapmeet.
Invoke the planning skill with the slash command below.
Direct the coordinator to treat product-requirements.md as the product source of truth.
Direct the coordinator to inspect the design system, repository instructions, and current source tree before assigning files.

/implementation-plan

You'll see a repository-specific implementation plan appear in the coordinator session. This becomes the blueprint for both lanes.

What is a seam?

A seam is the boundary where two independently built parts meet. Here, the seam is the fixed data or API shape shared by the frontend lane plus the backend or data lane.

Clear seams let each developer work inside an exclusive file set. The contract keeps both results compatible when the coordinator combines them.

Check that the frontend lane names every file it owns.
Check that the backend lane names every file it owns.
Compare both file lists to confirm that no file appears twice.
Check that frontend scope includes the listings grid, category filter, listing detail, and post-a-listing form.
Check that AI assistance, pricing, negotiation, offers, bids, messaging, reputation, recommendations, local discovery, and community stay deterministic and mocked.
Check that frontend scope uses the token-based design system with Day and Night themes.
Check that backend scope includes the five required listing and category endpoints with persistence to data/listings.json.
Approve the plan only after its API contract and acceptance checks provide observable evidence for the complete MVP loop.

Turn the plan into an issue

The implementation plan defines the work. The file-issue skill reorganizes that plan into the factory's durable GitHub record.

Invoke the issue skill with the slash command below.
Direct the coordinator to convert the approved plan into an issue body saved as issue.md.
Check that issue.md contains ## Goal, ## Lanes, ## Contracts, ## Acceptance, and ## Protocol.
Confirm the goal names the browse, filter, detail, and persisted listing-creation loop.
Confirm the frontend lane separates real core screens from deterministic mocked experiences.
Confirm the backend lane owns the five required endpoints and JSON persistence.
Confirm both lanes have exact, non-overlapping owned-file lists.
Confirm every acceptance check names observable browser, response, persistence, or log evidence.

/file-issue

You'll see the approved implementation plan reorganized as an issue body. The draft now connects each lane to a bounded scope plus measurable evidence.

Add the rule that only issue comments count as factory communication.
Set the coordinator comment prefix to [coord].
Set the frontend comment prefix to [lane:fe].
Set the backend or data comment prefix to [lane:be].
Restrict status values to active, pending, blocked, or done.
Review the issue draft against the approved implementation plan.
Approve the issue draft once every protocol rule is present.

Why use a fixed protocol?

Prefixes identify who wrote each message. Status values show whether a lane is working, waiting, unable to continue, or complete.

A fixed vocabulary makes the ordered issue comments readable by people plus agents. Every factory decision becomes traceable.

Create the issue and assign both lanes

The approved draft becomes authoritative when the coordinator publishes it on the learner's fork. The repository harness provides the issue-creation path for this workflow.

Create the issue from the coordinator's 3-prime-swapmeet session by running the repository tool below:

harness/tools/new-issue.sh "Build the SwapMeet marketplace MVP" issue.md

What does this tool do?

The repository tool creates one issue on the learner's fork from the approved issue content. This keeps the factory record tied to the repository-defined workflow.

The new issue becomes the only place where assignments, questions, evidence, merge notices, or final results are recorded.

Record the assigned issue number here: <issue>.
Have the coordinator record issue #<issue> in the repository-defined coordinator state.

Publish the clone-to-lane assignments with the repository artifact by running:

harness/tools/lane-claim.sh [[ISSUE_NUMBER="<issue>"]] fe 1-prime-swapmeet
harness/tools/lane-claim.sh [[ISSUE_NUMBER="<issue>"]] be 2-prime-swapmeet

You should see two new [coord] comments assigning the frontend and backend lanes to their clones.

What belongs in each assignment?

The assignment names one lane plus its exact owned files.
The assignment repeats that lane's contract responsibility.
The assignment states the evidence required from ./start.sh plus the running application.

Keep the existing 1-prime-swapmeet window unchanged.
Keep the existing 2-prime-swapmeet window unchanged.
Ask the coordinator to generate both gated worker prompts by submitting the prompt below.

Create two copy-paste bootstrap prompts for issue #[[ISSUE_NUMBER="<issue>"]].
Create one prompt for 1-prime-swapmeet as the fe lane.
Create one prompt for 2-prime-swapmeet as the be lane.
Put the repository URL and full issue URL in each prompt.
Tell each worker to inspect its local clone and load the issue's owned files, contract, and acceptance checks into context.
Require each worker to post an author-stamped pending message that says context loaded and ready for release.
After posting readiness, require each worker to keep polling without editing files, creating a branch, or starting implementation.
Allow work only after an author-stamped [coord] active release that follows both readiness messages.
After release, require each worker to invoke the lane-developer workflow, create its assigned lane branch, post an author-stamped active message, and implement only its owned files.
Accept go, execute, or release the kraken as human release phrases.

What should the coordinator produce?

Each prompt names exactly one clone and lane.
Each prompt contains the repository URL plus the full issue URL.
Each prompt requires the worker to summarize its owned files, contract, and acceptance evidence in the readiness message.
Each prompt holds the worker at the release gate while it polls for a stamped coordinator instruction.

You'll see two self-contained prompts in the coordinator session. Neither worker has received them or started implementation yet.

Before you check the issue, do you expect every lane boundary plus protocol rule to be visible without consulting the coordinator's local session?

Open issue #<issue> on your SwapMeet fork.
Confirm that the goal names the browse, filter, detail, and persisted listing-creation loop.
Confirm that the issue keeps the broader product experiences deterministic and mocked.
Confirm that backend scope lists the five required endpoints and data/listings.json persistence.
Confirm that the issue body shows two mutually exclusive owned-file lists.
Confirm that the issue body fixes the shared request and response contract.
Confirm that the issue body states lane-specific browser, response, persistence, and log evidence.
Confirm that both assignment comments carry the 3-prime-swapmeet author stamp and name their assigned clone.

You will see two lanes with separate file ownership. The issue will also preserve the real-versus-mocked boundary, the fixed API contract, and evidence requirements for the complete MVP loop.

Below the issue body, you'll see two separate coordinator assignments. Neither developer clone has retrieved an assignment into local state.

That is the planning boundary locked in. Every future factory decision now has one visible home.

Issue or assignments missing?

Confirm that the coordinator session is rooted at 3-prime-swapmeet.
Check that the file-issue draft was approved before the issue tool ran.
Have the coordinator post any missing lane assignment as a separate issue comment.

Ask for help with the coordinator workflow: Why is my SwapMeet issue missing its plan or coordinator assignments?

Your issue now contains the complete operating plan for the factory. Next, you'll prove that neither developer clone knows its assignment until it polls this record.

Prove the Clones Share No Memory

Your coordinator has converted the listing-page plan into one GitHub issue. That issue now holds every fact the lanes need.

The next risk is hidden context leakage between developer windows. This step tests whether either Claude Code session can prove an assignment before it polls the issue.

In this step, get ready to:

Load the lane-developer workflow in both developer windows.
Test what each lane can prove from local state before polling.
Record the isolation result without changing code or creating branches.

Prepare the developer sessions

The coordination-protocol skill defines the shared vocabulary. The lane-developer skill tells each developer how to read, build, validate, report, and poll without leaving its owned scope.

Switch to the 1-prime-swapmeet Claude Code window.
Invoke both harness skills with the slash commands below.
Repeat the same skill invocations in 2-prime-swapmeet.
Keep the issue number and assignment details out of both developer chats.
Leave the issue poller unused in both developer windows.

/coordination-protocol
/lane-developer

Both developer windows now have the lane workflow ready. Their chats still contain no copied issue details.

Test each clone's local knowledge

A trustworthy assignment needs evidence from an authoritative source. This check asks each developer to cite what its current session can prove.

Before you ask either developer, do you think a role label alone can reveal its owned files or latest coordinator message?

Submit the prompt below to the frontend developer session.
Submit the same prompt to the backend developer session.

Using only this session's current local state, cite your exact owned files, interface contract, required acceptance evidence, and latest [coord] message. Do not poll the issue or inspect remote comments.

You should see the frontend developer explain that current local state cannot prove any requested detail. That shortfall is intentional.

Leave the files in 1-prime-swapmeet unchanged.
Do not create a branch in 1-prime-swapmeet.
Ask the backend or data developer to cite its exact owned files using only current local state.
Ask the backend or data developer to cite its interface contract using only current local state.
Ask the backend or data developer to cite its required acceptance evidence using only current local state.
Ask the backend or data developer to cite the latest [coord] message using only current local state.

You should see the backend or data developer report the same evidence gap. It cannot prove an assignment from its current context.

Leave the files in 2-prime-swapmeet unchanged.
Do not create a branch in 2-prime-swapmeet.

You now have the result this test was built to expose. Both windows lack locally provable assignments.

Load both workers and hold at ready

The coordinator prompts now provide the missing context without granting permission to build. Each worker reads its local code plus the authoritative issue, reports what it understands, then waits at the release gate.

Copy the frontend bootstrap prompt from the 3-prime-swapmeet session.
Switch to the 1-prime-swapmeet Claude Code window.
Submit the frontend bootstrap prompt.
Copy the backend bootstrap prompt from the 3-prime-swapmeet session.
Switch to the 2-prime-swapmeet Claude Code window.
Submit the backend bootstrap prompt.

Each worker inspects its local clone and reads the full issue URL. It then posts an author-stamped pending message that summarizes its owned files, contract, acceptance evidence, and readiness for release.

What proves a worker is ready?

The clone identity and lane agree with the author stamp.
The owned files match the lane assignment in the issue.
The contract summary matches the issue body.
The worker has not edited files, created a branch, or started implementation.

Switch to the 3-prime-swapmeet coordinator window.
Have the coordinator verify both readiness messages by submitting the prompt below.

Poll issue #[[ISSUE_NUMBER="<issue>"]] until both worker readiness messages appear.
Verify that each author stamp matches the claimed lane.
Confirm that both messages summarize owned files, contract, and acceptance evidence.
Do not release either lane yet.

You'll see one stamped frontend readiness message plus one stamped backend readiness message. Both workers remain idle while they poll for the coordinator's release.

Worker missing or starting early?

Stop any worker that edits a file or creates a branch before release.
Check that its bootstrap prompt includes the no-edit gate plus the full issue URL.
Help me restore the worker readiness gate.

Both workers now understand their assignments and are waiting behind one human-controlled gate. Next, you'll release the whole factory from the coordinator window.

Build the Lanes in Parallel

Your developer clones have proved the isolation gap. Each worker has now loaded its local code plus the authoritative GitHub issue into context.

Both workers are ready, but neither may build until the coordinator receives your release phrase. That single gate starts both lanes from one human-controlled decision.

In this step, get ready to:

Release both ready workers from the coordinator window.
Build each lane on its assigned branch within its exact owned-file list.
Prove each lane with acceptance evidence plus an issue-linked pull request.

Release both lanes

Both workers are polling the issue from a ready state. The coordinator now acts as the single release switch for the factory.

Before you release the workers, do you expect either lane to create a branch without a stamped coordinator instruction?

Switch to the 3-prime-swapmeet coordinator window.
Confirm that the issue contains valid stamped readiness messages from both workers.
Release both lanes by submitting the phrase below.

release the kraken

What does the release phrase do?

The coordinator accepts go, execute, or release the kraken as the release phrase.
The coordinator verifies both author-stamped readiness messages before publishing a stamped [coord] active release comment.
Both waiting workers retrieve the release through their existing issue-polling loop.
Each worker creates its assigned branch and posts a stamped active status before implementation.

You'll see the coordinator publish one stamped release after both readiness messages. The frontend plus backend workers then move from pending to active on their independent branches.

Keep the 3-prime-swapmeet session open while it polls for both worker start reports.
Confirm that the frontend start report names lane/<issue>-fe.
Confirm that the backend start report names lane/<issue>-be.

Worker still waiting after release?

Do not publish a release if either readiness message is missing or has the wrong author stamp.
Keep both workers at pending while the coordinator resolves the missing readiness report.
Help me diagnose a worker that stayed pending.

Build within the fixed contract

Exclusive ownership turns the contract into a safe seam. Each developer can change its assigned side while trusting the other lane to preserve the agreed shape.

Keep both worker sessions running while their released prompts execute.
Check that each worker treats issue #<issue> as its only implementation source.
Confirm that the frontend worker builds the real marketplace loop with the design system while keeping the wider product experiences mocked.
Confirm that the backend worker implements only the five required endpoints, validation, and persistence to data/listings.json.

Before you inspect the work, do you expect every changed path to belong to the lane that changed it?

Inspect the current changes from each developer clone by running:

git status

What does this ownership check show?

Git reports paths as modified, staged, or untracked. Every reported path must appear in that lane's owned-file list from issue #<issue>.

You should see only frontend-owned paths in 1-prime-swapmeet. You should see only backend or data-owned paths in 2-prime-swapmeet.

Seeing an unowned file?

Stop the affected lane before it makes another change.
Have the lane post [lane:fe] blocked or [lane:be] blocked through the issue tool.
Wait for the coordinator to resolve the ownership conflict on the issue.

Help me resolve a lane ownership conflict.

Natural boundaries are the right time to check for new coordinator guidance. Polling there keeps each lane current without creating a side channel.

Poll for new issue comments from each developer clone by running:

harness/tools/gh-poll.sh [[ISSUE_NUMBER="<issue>"]]

Why poll at a natural boundary?

A boundary gives the lane a stable point from which to process new comments. The developer can continue when the contract is unchanged.

A new coordinator reply becomes part of the same ordered record as the original assignment.

Continue against the fixed contract when the poller reports no new instruction.
Post [lane:fe] blocked or [lane:be] blocked if a question prevents contract-safe progress.
Wait for the coordinator's issue reply before changing the disputed area.
Poll the issue again before resuming the affected lane.

Poller stops during implementation?

Keep the lane unchanged until it can retrieve the authoritative issue record. A private guess would bypass the factory protocol.

Help me restore issue polling.

Prove each lane and open its pull request

A finished edit needs evidence from the running application. Each lane must prove the exact behavior named in its acceptance section.

Start the application from each developer clone by running:

./start.sh

What does this validation prove?

The startup script exercises the repository's author-defined application path.
Frontend evidence proves browsing, category filtering, listing details, listing creation, theming, and deterministic mocks.
Backend evidence proves the five routes, validation, JSON persistence, and request logs.

Capture browser evidence that the frontend can browse, filter, open, and submit listings.
Capture browser evidence that Day and Night themes use the repository design tokens.
Capture response and log evidence for every backend route required by issue #<issue>.
Create one listing and confirm that its record persists in data/listings.json.

The hard part is complete. Both lanes now have runtime evidence tied to the contract they implemented.

Application or evidence check failing?

Keep the affected lane uncommitted while the acceptance check fails.
Compare the failure with that lane's exact acceptance section.
Post the appropriate blocked status if the failure exposes a contract question.

Help me diagnose the failed lane evidence.

In the frontend developer window, have the lane-developer skill create a scoped commit containing only frontend-owned changes with refs #<issue>.
Have the frontend lane open an issue-linked pull request from lane/<issue>-fe.
Open the frontend pull request to confirm its file list stays within frontend ownership.
Record the frontend pull request number as <fe-pr>.
Have the frontend lane post [lane:fe] done: PR #<fe-pr> with its acceptance evidence through harness/tools/gh-post.sh.
Return to issue #<issue> to confirm the frontend done comment is recorded.

The frontend lane now has an open ownership-safe pull request plus a public evidence record.

In the backend or data developer window, have the lane-developer skill create a scoped commit containing only owned changes with refs #<issue>.
Have the backend or data lane open an issue-linked pull request from lane/<issue>-be.
Open the backend or data pull request to confirm its file list stays within backend or data ownership.
Record the backend or data pull request number as <be-pr>.
Have the backend or data lane post [lane:be] done: PR #<be-pr> with its acceptance evidence through harness/tools/gh-post.sh.
Return to issue #<issue> to confirm the backend or data done comment is recorded.

Before you perform the final check, do you expect either lane to be missing evidence from its issue comment or pull request?

Refresh issue #<issue> to confirm both lane done comments include their required acceptance evidence.
Open the frontend pull request to confirm it links back to the issue.
Open the backend or data pull request to confirm it links back to the issue.

You should see one [lane:fe] done: PR #<fe-pr> comment plus one [lane:be] done: PR #<be-pr> comment. Both open pull requests should contain only their lane's owned files plus the required evidence.

You have turned two isolated developer clones into parallel delivery lanes with traceable evidence. Next, the coordinator takes control of review and integration.

Coordinate, Merge, and Validate

Both developer lanes have finished their scoped work. The shared GitHub issue now links two evidence-backed pull requests.

Parallel output is unfinished until one coordinator verifies each lane against its ownership, contract, and evidence. The same coordinator must prove the combined application before closing the issue.

In this step, get ready to:

Poll the issue from the coordinator clone to collect both lane results.
Review both pull requests against ownership, contracts, evidence, and issue-linked commits.
Merge sequentially before validating the complete marketplace MVP and closing the issue.

Poll the issue as coordinator

The coordinator skill provides the review, merge, validation, and closure procedure. The issue remains the only place where Claude Code can retrieve authoritative updates from the isolated developer clones.

Switch back to the Claude Code window for 3-prime-swapmeet.
Load the coordinator skill in that session.
Retrieve the latest issue comments by running this command:

/coordinator

harness/tools/gh-poll.sh <issue>

What does this command do?

The gh-poll.sh tool retrieves issue updates into the isolated coordinator clone.
The coordinator can now reason from the recorded comments without relying on another agent's local memory.

You'll see [lane:fe] done: PR #<fe-pr> plus [lane:be] done: PR #<be-pr> with their acceptance evidence. Any earlier blocked questions remain visible in the ordered issue history.

Compare the polled comments with the assignments recorded in issue #<issue>.
Resolve any remaining blocked question from repository evidence.
Record each resolution in a coordinator issue comment.
Post one [coord] amendment addressed to both lanes when repository evidence requires a contract change.

Missing a lane result?

Confirm you ran the poller from 3-prime-swapmeet with the same issue number used by both lanes. Keep the issue open until both done comments appear with their evidence.

Ask for help with the coordinator poll before reviewing either pull request: Why is my coordinator clone missing one lane's issue comments?

Review and merge each pull request

A pull request reaches the default branch only after it passes the coordinator gate. That gate covers exclusive file ownership, the fixed interface contract, acceptance evidence, and the scoped commit reference.

Review #<fe-pr> against the frontend-owned file list in issue #<issue>.
Confirm every changed path belongs to the frontend lane.
Compare the frontend implementation with the fixed interface contract.
Check the frontend browser evidence for browse, filter, detail, listing creation, themes, and deterministic mocks.
Verify the scoped commit includes refs #<issue>.
Post [coord] blocked through the issue when any review gate fails.
Merge #<fe-pr> only after every gate passes.
Post a [coord] active issue comment recording that #<fe-pr> merged first.

Why merge one at a time?

A sequential merge gives the coordinator a stable checkpoint after each lane enters the default branch. A failed check can then be traced to one merge instead of an untested combination.

Update 3-prime-swapmeet to the fork's default branch through the repository workflow.
Run the relevant repository-defined checks against the first merged state.

You should see the relevant checks pass with #<fe-pr> on the default branch. This proves the first merge is stable before the second review begins.

Why update before the second review?

The second pull request must be judged against the branch it will actually join. Updating the coordinator clone exposes contract conflicts that were invisible while both lanes worked independently.

Review #<be-pr> against the backend or data-owned file list in issue #<issue>.
Confirm every changed path belongs to the backend or data lane.
Compare the backend or data implementation with the fixed interface contract.
Check the backend response, validation, JSON persistence, and request-log evidence.
Verify the scoped commit includes refs #<issue>.
Post [coord] blocked through the issue when any review gate fails.
Merge #<be-pr> only after every gate passes.
Post a [coord] active issue comment recording that #<be-pr> merged second.

Both pull requests are now merged in a controlled order. The issue records which change entered the default branch at each checkpoint.

Did a review gate fail?

Leave the affected pull request unmerged. Post [coord] blocked with the exact owned-file, contract, commit, or evidence gate that failed.

Keep the correction on the issue so the responsible lane can retrieve it through polling. Help me diagnose a SwapMeet pull request that failed the coordinator gate.

Validate the combined application

The two pull requests have passed separately. The final gate tests the complete marketplace loop against the fixed API contract, design system, repository checks, persistence, and server logs.

Update 3-prime-swapmeet to the default branch after the second merge.

Before you run the combined application, do you expect both independently built lanes to satisfy the shared contract across the complete marketplace flow?

Start the merged SwapMeet application by running:

./start.sh

What does this check prove?

The application starts from the coordinator's updated default branch.
The browser and server logs now exercise the combined frontend plus backend or data result.

You will see the repository's successful startup output. Keep that process running while you verify the marketplace flow in the browser.

Did the combined application fail to start?

Confirm the coordinator clone is on the updated default branch.
Confirm both pull requests show as merged before retrying the startup check.

Use the startup output to trace the first failing repository check. Why does the merged SwapMeet application fail when both lane pull requests passed separately?

Open the running application using the address reported by the startup output.
Confirm the browse view shows a grid of listing cards with price, title, location, seller trust, and no more than one badge per card.
Select a category and confirm the grid shows only matching listings.
Open one listing and confirm its detail view matches the selected item.
Submit a valid item through the post-a-listing form.
Refresh the application and confirm the new listing remains available.
Switch between Day and Night themes and confirm both states remain readable.
Trigger the mocked experience named in the issue and confirm it returns deterministic local data.

What does the browser check prove?

The browser check proves that the frontend and backend satisfy one shared contract. The persisted listing shows that the combined buyer-and-seller loop survives beyond a single page state.

Before the coordinator runs the final validation suite, do you expect the sequentially merged default branch to pass every repository gate?

Have the coordinator skill run the repository-defined validation suite from 3-prime-swapmeet.
Inspect the validation result for a passing status on every required gate.
Inspect the server logs for GET /api/listings, GET /api/listings?category=, GET /api/listings/:id, GET /api/categories, and POST /api/listings requests.
Confirm that the submitted listing exists in data/listings.json after the final check.

You will see every required repository check pass. The server logs and persisted JSON record will support the same marketplace behavior you observed in the browser.

Did a combined validation fail?

Keep issue #<issue> open. Compare the failed gate with the merged diff, the fixed contract, and the lane evidence before recording the failure as [coord] blocked.

Close the issue only after the failed gate passes on the combined default branch. Help me trace a failed combined SwapMeet validation gate.

Have the coordinator skill post one [coord] done comment through issue #<issue>.
Include links to #<fe-pr> and #<be-pr> in that comment.
Include the combined validation and final server-log evidence in that comment.
Close issue #<issue> after the final comment appears.

That closes the loop. Your three isolated clones have produced one validated SwapMeet marketplace MVP with a complete issue record proving how every decision reached the default branch.

Secret mission

Amend a Contract Mid-Flight

A shared contract can change after both lanes have started work. Route one controlled amendment through the same issue so every decision, acknowledgement, code change, and validation result stays traceable.

Clean Up Your Resources

Your three-clone factory is local, so its clone folders add no ongoing infrastructure cost. Choose whether to keep those folders, pause the local sessions, or delete the clones while preserving your GitHub issue and merged pull requests.

Resources you used:

Local coordinator clone folder: 3-prime-swapmeet.
Local frontend clone folder: 1-prime-swapmeet.
Local backend or data clone folder: 2-prime-swapmeet.
Local application processes started by ./start.sh in any clone.

Keep everything running

No action is needed. Choose this if you want to continue experimenting with the three-clone factory.

Leave 3-prime-swapmeet in place for coordinator work.
Leave 1-prime-swapmeet in place for frontend lane work.
Leave 2-prime-swapmeet in place for backend or data lane work.
Leave the three Claude Code windows open while you continue building.
Retain the closed issue plus both merged pull requests as the factory audit record.

The local folders create no infrastructure charges. Future Claude Code requests remain subject to your existing subscription or Console billing.

Pause - I'll come back to this later

Stop the local processes to free up memory. Keep the clone folders so every role can resume from its existing workspace.

Stop any process started with ./start.sh in the coordinator Terminal window.
Stop any process started with ./start.sh in the frontend Terminal window.
Stop any process started with ./start.sh in the backend or data Terminal window.
End each Claude Code session from its window.
Leave all three clone folders in place.

Your local memory is freed while the branches plus repository state remain available. The closed issue continues to preserve every assignment, amendment, status update, pull request, and validation result.

Delete - I don't want to use this again

Removing the clone folders permanently discards any uncommitted local work. Your merged default branch is already safe on the fork.

Stop every process started with ./start.sh across the three Terminal windows.
End the Claude Code session in each window.
Return to the shell prompt inside 3-prime-swapmeet.
Remove all three local clone folders by running these commands:

cd ..
rm -rf 1-prime-swapmeet 2-prime-swapmeet 3-prime-swapmeet

What Does This Cleanup Do?

The first command moves Terminal from 3-prime-swapmeet to the folder containing all three clones.
The second command removes 1-prime-swapmeet, 2-prime-swapmeet, plus 3-prime-swapmeet from your Mac.
The closed GitHub issue plus both merged pull requests stay on the fork as your evidence record.

Cleanup complete. The three disposable local workspaces are gone.

Your closed issue plus merged pull requests still preserve the factory plan, contract amendment, lane evidence, sequential merges, and final validation.

Clone Folders Still Present?

Check that Terminal moved to the folder containing all three clones before the removal command ran.
Stop any remaining ./start.sh process before retrying the cleanup.
Ask for help with the local cleanup.

Nice Work!

Outstanding work! Your three isolated Claude Code clones shipped a coordinator-validated SwapMeet marketplace MVP through two ownership-safe GitHub pull requests.

You've learned how to:

Run a three-clone factory with one coordinator, two isolated developer lanes, and clone-specific Git identities.
Ship a working marketplace MVP that browses and filters listings, opens item details, and persists new listings in data/listings.json.
Protect parallel delivery with exclusive ownership and fixed contracts backed by browser, response, persistence, and server-log evidence.
Secret Mission: Process a mid-flight contract amendment entirely through issue polling before both lanes make ownership-safe changes.

Ready to quiz yourself?