First Issue Walkthrough: Completion

This page covers the review, PR creation, merge, and teardown phases. For the overview, see the main walkthrough page.

Step 6: SENTINEL reviews every segment

After each segment commit, SENTINEL is provisioned in its own fresh Coder workspace and evaluates the segment. SENTINEL writes segment-N-eval.md with either APPROVED or REJECTED.

SENTINEL checks the same things a human reviewer would: correctness, security, test coverage, edge cases, naming consistency, and whether the segment satisfies the contract.

text

[sentinel] evaluating segment-1 for ticket-42
[sentinel] segment-1-eval.md: APPROVED
[forge] starting segment-2 for ticket-42
[sentinel] evaluating segment-2 for ticket-42
[sentinel] segment-2-eval.md: REJECTED - missing concurrent-request test
[forge] revising segment-2 for ticket-42
[sentinel] segment-2-eval.md: APPROVED

Step 7: SENTINEL final review and FORGE opens the PR

When all segments are approved, SENTINEL performs a final review of the whole branch. It writes final-review.md, which must be APPROVED before the pull request can be opened.

Once approved, FORGE pushes the branch to GitHub and opens a pull request. It also writes STATUS.json with status PR_OPENED.

text

[sentinel] final-review.md: APPROVED for ticket-42
[forge] pushing branch forge/ticket-42
[forge] PR #123 opened for ticket-42
[forge] STATUS.json -> PR_OPENED { pr_number: 123 }

PRs are always linked to the issue

FORGE includes Closes #42 in the PR description, so the issue closes automatically when VESSEL merges.

Step 8: VESSEL polls CI and merges

VESSEL polls the GitHub API for the pull request status, checks the mergeable field, and watches CI checks. The default polling interval is 10 seconds.

VESSEL handles merge conflicts, CI failures, required reviews, and branch protection rules. When the PR is mergeable and all checks pass, VESSEL performs a squash merge.

text

[vessel] monitoring PR #123 for ticket-42
[vessel] PR #123 mergeable=true, checks=passed
[vessel] squash-merged PR #123, ticket-42 merged

Step 9: LORE documents the change

After the merge, LORE writes the required documentation:

An ADR in docs/adr/ for architectural changes.
An updated CHANGELOG.md entry.
Optional README or inline documentation updates.

text

[lore] documenting ticket-42
[lore] wrote docs/adr/0042-rate-limiting-middleware.md
[lore] updated CHANGELOG.md
[lore] committed documentation to main

Step 10: NEXUS tears down the workspace

After the PR is merged and documentation is committed, NEXUS destroys the FORGE workspace. No lingering source trees, cached build artifacts, stale tokens, or disk bloat.

text

[nexus] ticket-42 complete, scheduling teardown
[nexus] tearing down workspace ws-forge-7a3f
[nexus] worker forge-7a3f returned to idle pool
[nexus] next poll in 60s

No credentials survive teardown

The GitHub session and LLM access live in the Coder control plane, not in the workspace. Even if a workspace were inspected before teardown, an attacker would find only repository code.

How to watch the whole flow

Source	What it shows	Command
OpenFlows orchestrator logs	Follow the main orchestrator process.	`docker logs -f openflows`
Coder workspace events	Logs workspace provisioning and tunnel connections.	`docker logs -f coder`
GitHub issue timeline	NEXUS posts progress comments and PR reference.	Open the issue on GitHub.
GitHub PR checks	VESSEL waits here before merging.	Open PR → Checks tab.
Redis SharedStore	Raw state machine keys and event ring.	`redis-cli MONITOR`
OpenFlows TUI	Real-time dashboard showing tickets, workers, and PRs.	`cargo run -p openflows-tui`

Sample log sequence

Phase	Log line	Meaning
NEXUS detection	`[nexus] discovered issue #42`	Issue is now a ticket in SharedStore.
FORGE planning	`[forge] writing PLAN.md for ticket-42`	PLAN.md is being written.
SENTINEL plan review	`[sentinel] CONTRACT.md: AGREED for ticket-42`	FORGE can begin implementation.
FORGE implementation	`[forge] committed segment-1`	One segment is complete.
SENTINEL segment eval	`[sentinel] segment-1-eval.md: APPROVED`	Implementation advances.
Final review	`[sentinel] final-review.md: APPROVED`	FORGE will now open the PR.
PR created	`[forge] PR #123 opened for ticket-42`	VESSEL takes over.
VESSEL merge	`[vessel] PR #123 mergeable=true, checks=passed`	PR is about to be merged.
Teardown	`[nexus] tearing down workspace ws-forge-42`	Workspace destroyed.

bash

# Start the real-time dashboard
cargo run -p openflows-tui

Common questions

How long does the full cycle take? A simple documentation fix can complete in minutes. A multi-segment feature with long CI can take an hour or more.

What if SENTINEL rejects the plan? FORGE revises and SENTINEL reviews again. If agents cannot agree, NEXUS marks the ticket AwaitingHuman.

Can I watch the workspace like a human developer? Yes. You can open the workspace in Coder's web IDE or use coder ssh. However, do not edit files manually unless you intend to take over the ticket.

What happens if CI is flaky? VESSEL is patient and will retry the mergeable check. If CI fails consistently, VESSEL escalates to AwaitingHuman after the configured timeout.