Skip to content

Builder-Founder Operating Loop

Turn useful energy into repeatable evidence

Prepared by Oluwasegun Olumbe.

This page is the operating loop for repoctx, PullPass, and the wider trust-layer work. It is for Codex sessions, maintainers, contributors, and company reviewers who need the same rhythm to survive across branches, pull requests, releases, and pilots.

The point is simple:

clear context
focused change
visible gate
human decision
durable evidence

repoctx gives the context foundation. PullPass gives the merge-safety gate. The maintainer turns both into a practice that can be repeated by one founder today and a company team tomorrow.

Tool Boundaries

repoctx is the product surface. It should stay the command and MCP server that users install first when they need repository context, PR review context, workspace reports, and agent-facing evidence.

PullPass is the merge-safety gate. It should stay focused on review readiness, governance mode, policy checks, CI state, CODEOWNERS, conversations, and the final human decision before merge.

impact-map is currently the analyzer and proving ground. Use it when scope is unclear, when import-neighbor evidence matters, or when a diff needs validation against the original change request. If the same impact-map behavior becomes part of the normal user workflow, graduate that behavior into repoctx instead of asking users to choose between two overlapping context tools.

The rule is simple:

Question Use
What should an agent or reviewer know before changing this repo? repoctx
Is this PR ready to merge under the repo's governance rules? PullPass
What files, import neighbors, tests, or missed diff areas might this change affect? impact-map

This keeps the public story clear while leaving room for impact-map to experiment with analysis that can later strengthen repoctx context packs and PR review output.

Every Session Loop

Use this loop at the start of every meaningful coding-agent session.

Step Action Evidence
1. Orient Check git state, current branch, open PRs, and latest roadmap item Clean or explained worktree, known base branch, no hidden conflict
2. Map Run repoctx context for the task and impact-map when scope or risk is unclear Primary files, related files, tests, risks, and validation commands
3. Choose Pick one deliverable that moves the trust layer forward A branch, issue, PR, docs page, release task, or proof artifact
4. Change Make the smallest complete change that satisfies the deliverable Focused diff with no unrelated cleanup
5. Prove Run the relevant local checks and record any skipped checks CI command output, docs build, PullPass result, or explicit no-test rationale
6. Gate Open or update a PR and let review gates speak before merge CI, PullPass readiness, review state, CODEOWNERS state, conversations
7. Decide Record the owner or reviewer decision PR review, merge note, release note, or trust-layer decision record
8. Handoff End with current state and next remaining goal Clean worktree, PR link, check status, and next action

This keeps sessions from becoming scattered. If a session cannot finish the whole objective, it should still leave one clearer artifact behind.

Definition Of Ready

A trust-layer task is ready to start when these are known:

  • The target repository and base branch.
  • The user-facing goal or governance question.
  • The expected risk level: docs, code, release, dependency, auth, data, deployment, or security-adjacent.
  • The validation command or reason validation is not applicable.
  • The review path: solo owner decision, maintainer review, team review, company review, or high-risk review.

If these are not known, the first deliverable is context: a repoctx report, impact map, issue note, or pilot preflight record.

Definition Of Done

A trust-layer task is done only when the evidence matches the claim.

  • The branch diff is focused and reviewed.
  • Relevant tests, docs builds, audits, or smoke checks pass.
  • PullPass result is captured when a merge decision is involved.
  • Any WARN or FAIL state is explained before merge.
  • Version impact is marked as none, patch, minor, or major.
  • Public evidence avoids local absolute paths, secrets, customer data, private source, and confidential logs.
  • The remaining plan is updated instead of being left in chat memory.

Governance Ladder

Mode Use when Merge bar
Solo One accountable maintainer owns the repo Admin merge can be valid, but CI, PullPass, and the owner decision must be visible
Small team A small engineering team shares review Require one human reviewer, required checks, and CODEOWNERS for sensitive paths
Company A company evaluates or adopts the workflow Require CODEOWNERS, status checks, resolved conversations, governance evidence, and release notes
High-risk Auth, payments, data, deployment, secrets, or incident-prone code changes Add stricter policy checks, explicit risk review, and stronger release or rollback evidence

The same operating loop should work in every mode. The approval bar changes as the stakes rise.

Evidence Ledger

Use this as the lightweight record for a PR, release, pilot, or company review.

Trust-layer evidence

Repository:
Branch or PR:
Goal:
Risk mode:
Version impact:

Context:
- repoctx artifact:
- impact-map artifact:
- related repos:

Change:
- focused deliverable:
- changed domains:
- tests or docs touched:

Gate:
- CI:
- PullPass mode:
- PullPass verdict:
- reviewer or owner:
- CODEOWNERS:
- conversations:

Decision:
- merge decision:
- rationale:
- warnings accepted:

Release or proof:
- changelog or release note:
- tag or deploy:
- public proof:
- private evidence boundary:

Next:
- remaining blocker:
- next smallest action:

The ledger can live in a PR description, merge note, release note, company pilot issue, or proof run. The format matters less than the discipline: context, gate, decision, evidence.

What To Track Across Sessions

Track Question Artifact
Product Is repoctx still the context foundation? README, docs, CLI/MCP behavior, tests
Gate Is PullPass still the merge-safety signal? PullPass workflow, local report, PR check, policy mode
Release Can another maintainer understand what shipped? SemVer impact, changelog, tag, GitHub release
Governance Can a company see who was accountable? CODEOWNERS, review policy, branch protection, decision record
Evidence Can proof be shared safely? Proof index, sanitized links, public/private boundary
Feedback Did reviewer concerns become action? Pilot feedback issue, outcome label, roadmap update

When a session resumes, inspect these tracks before declaring the plan complete. A green check is useful evidence, but it is not the whole operating system.

Next Best Action Rule

When the plan feels large, choose the next action in this order:

  1. Fix a failing gate.
  2. Close an open PR or conflict.
  3. Add missing verification for an already shipped claim.
  4. Tighten the company-facing evidence boundary.
  5. Improve repoctx or PullPass behavior that would make the next pilot easier.
  6. Update roadmap, proof index, or release notes so the current state is not trapped in memory.

This keeps the builder-founder path practical: build, prove, publish, review, repeat.