Human
Adam Fortuna
@adamfortuna Founder & developer. Triages, assigns work to people or Jules, reviews, merges, and deploys.
Also runs Nautilus, writes most of the agent commands, and sweeps the Ready to Deploy lane.
01 · The cast
People, agents, and the services between them
Three colors run through every diagram on this page. Orange is a person. Blue is an agent. Green is a service holding state or firing a webhook.
People
Decide what to build, sign off, and press deploy.
Human
Developers who deploy
Three developers, Adam included, with permission to merge into main and run the deploy workflows.
When one of them assigns an issue, they become the PR's assignee: the person responsible for getting it to Ready to Deploy.
Human
Newer developers
Three more developers who build and review but do not deploy yet.
They work in Conductor or their own editor, open PRs, and hand them to the reviewer bot or to a deployer.
Human
Product Developer
Turns product feedback into tasks on a Hub task board, writes the prompt for each, and picks a branch.
Signs off on plans, drops tasks into "Ready to Develop", and clicks "Send for review" when a branch looks done.
Human
Hardcover community
Readers on Discord, support email, and the public roadmap who report bugs and upvote feature requests.
The source of most new work.
Agents
Collectively "Jules". Two GitHub accounts, many roles.
Agent
Jules · entry point
Interprets a request, answers from the vault when it can, delegates when it cannot.
The name everyone uses for "the bots". Delegates codebase questions to Eiko.
Agent
Jean · the coder
@jules-hardcover Writes and modifies code in the Hardcover codebase.
Runs /issue-async, /address-review, /fix-gh-ci, /rebase-pr, /pr-evidence and /hub-task. Also applies risk labels to new PRs.
Agent
Electra · the reviewer
@jules-hardcover-reviewer Reviews code and pull requests with a fixed rubric and evidence table, then moves the card on the PR board.
Runs /review. Verdicts: approve, request changes, or comment. Also runs the 2-hourly project audit and weekly review audit.
Agent
Eiko · the verifier
Verifies claims against the Hardcover codebase: is a reported bug real, and where does the code live?
Read-only. Validates issues and answers codebase questions for the other agents.
Agent
Grandis · the planner
Breaks a request into a plan: scope, steps, risks, estimate. Drafts GitHub issues from conversation context.
Turns a Discord thread or support conversation into a reproducible issue.
Agent
Babel · search
Answers questions from the Obsidian vault. Called by other agents.
Agents do not call agents; they call Babel.
Agent
Hanson · support
Drafts Help Scout support replies using vault context. Drafts only, never sends.
Email to jules@hardcover.app lands in Help Scout; Hanson has a draft waiting when a person opens it.
Agent
Nadia · digest
Reads the community, writes periodic digests, hands observations to Babel.
Posts under the @hardcover identity on Discord.
Services
Where state lives and where webhooks come from.
Service
Nautilus (Hub)
The company brain and the agent dispatcher. Hears GitHub webhooks, picks an agent, model and location, and records every action as a Run.
Rails app on a Mac Mini behind a Cloudflare tunnel. Also hosts the product task boards, timelines, and the development board.
Service
GitHub
Issues, pull requests, Actions CI, and the "Hardcover Pull Requests" project board.
Every state change here is a webhook that Nautilus can react to.
Service
Conductor Cloud
Cloud workspaces where the coding agents do their work: one per issue or branch, with parallel sessions.
Reviews of agent PRs run as a second session inside the author's workspace.
Service
Nautilus host bridge
The Mac Mini that hosts Nautilus also runs the inline agents and any bridge agent configured to run "on Nautilus".
Each run gets its own git worktree and port block.
Service
Help Scout
The support inbox behind jules@hardcover.app. Bugs found here become issues, or get fixed on the spot.
Hanson drafts the reply; a person decides what happens next.
Service
GitHub Actions CI
RSpec, Rubocop, React lint and tests, N+1 report, page budgets, migration report, scope drift, generated types.
Three jobs are required for merge readiness; the rest are conditional on what changed.
Service
Deployments repo
Kubernetes, Helm and SOPS on DigitalOcean. One manually dispatched GitHub Action per app, per environment.
No agent and no merge ever deploys. A person does.
02 · Intake
Where work comes from
Bugs arrive from Discord, email, error tracking and support. Features arrive from the public roadmap and from product planning. Almost all of it is normalized into one of two shapes: a GitHub issue or a Hub product task. Then someone, or something, picks it up.
Widths are rough proportions to show the shape of the flow, not measured counts. Hover a node to trace its paths.
03 · The loop
Issue in, approved PR out
Every arrow here is either a GitHub webhook hitting Nautilus, or Nautilus dispatching a command into a workspace. Whoever holds the baton is 'in control'; the hand-offs are what make it a loop instead of a script. Scroll the steps.
Step 1 of 8 · In control: Human Someone assigns the issue to Jules
What a dispatch looks like
Nautilus records every action as a Run with a live log. The command it builds reads like this:
cd ~/code/hardcover && claude -p /review 4599 full --model opus --effort highBinary, model and effort come from the agent's model alias. If the model starts with gpt-, the binary is codex.
Guard rails
- Three consecutive agent review rounds, then a human is pinged.
- Three CI-fix attempts per PR per day.
- Per-agent caps on concurrent workspaces and sessions.
- Migrations, schema, GraphQL and Hasura changes need a person's sign-off.
- The reviewer can never approve while CI is still pending.
Assignee vs. reviewers
Every PR has one assignee: the developer responsible for getting it to Ready to Deploy, usually whoever assigned the issue in the first place. Reviewers are whoever has to say yes before that: always @jules-hardcover-reviewer, plus the assignee when Jean wrote the code, plus a person for migrations, schema, GraphQL or Hasura changes.
Humans in the same loop
Assign the issue to yourself, build it, then either assign it to @jules-hardcover to finish, request @jules-hardcover-reviewer on your own PR, or run /goose:pr 4599 locally. Goose drives the PR through CI, review and fixes until it reaches a clean approve with zero findings.
04 · The PR board
Six lanes, two of them human-only
Every open PR sits in one Status lane on the Hardcover Pull Requests project. Electra moves cards based on her verdict. Nobody but a person can drag a card into Ready to Deploy or Done.
In Progress
moved by servicePR exists but is not ready. Drafts and work still under way.
PR #4599 opened
Pull Request Review
moved by agentReviewer requested. Set when a PR opens and whenever Electra posts a comment-only round.
Review Iterations
moved by agentElectra requested changes. Jean (or the author) is addressing them.
PR Review Passed
moved by agentApproved by the reviewer. Now the assignee verifies it and decides whether it ships.
Ready to Deploy
moved by humanThe assignee has verified it. Nautilus posts merge readiness; a deployer sweeps this lane to merge.
Done
moved by humanMerged into main and deployed.
Press play to watch a PR travel: opened, reviewed, sent back once, approved, verified, shipped.
05 · Feature work
Three doors into the same room
Bugs are small and uniform. Features are not, so they can start in three different places. All three end at a pull request in the loop above.
Door 1
From a GitHub issue
Someone writes it up as an issue.
- Triage: Area, Priority, Code labels
- Assign to a person or to @jules-hardcover
- Same PR → review → merge loop as bugs
Door 2
From the public roadmap
Readers add and upvote feature requests at roadmap.hardcover.app.
- A developer picks a well-voted idea
- Builds it in Conductor, opens a PR
- Requests @jules-hardcover-reviewer or runs /goose:pr
- Roadmap item moves to shipped; changelog entry
Door 3
From a product task board
A bigger feature gets a Hub product with its own board and timeline.
- Product developer writes a prompt per task
- Research & Plan → sign off → pick a branch
- Ready to Develop dispatches /hub-task into one shared branch workspace
- Agents work the board; screenshots land on the batch PR
- "Send for review" runs /goose:pr until it passes
Inside a product task board
Each product in Hub has its own board. A task carries its prompt, a plan, and a destination branch. One persistent Conductor Cloud workspace serves the branch, with as many parallel sessions as the branch's worker limit allows. All of a branch's tasks land on one batch PR.
Tap a lane for what it means. Colors show who moves cards into it.
06 · Release
A few times a week, the lane gets swept
There is no merge queue and no continuous deployment on purpose. Merging is a decision and deploying is a button, both pressed by a person.
- 01
Sweep the lane
Three to seven times a week, one of the three developers with deploy access opens the Ready to Deploy lane. Everything there has a reviewer approval and its assignee's sign-off.
- 02
Merge, one after another
Merge the whole batch into main by hand, one PR after another. Nautilus already posted a "Ready to merge" check; conflicts trigger an automatic /rebase-pr first.
- 03
Deploy to staging
Run "Deploy Application from Source" in the deployments repo for each app that changed, with environment set to stage. The Code: labels on the PRs say which.
hardcover-railshardcover-apihardcover-workerhasurasearch-proxyrecommendations-api - 04
Verify on staging
Click through what shipped. Watch Grafana and Bugsnag for anything new.
- 05
Deploy to production
Same workflows, environment set to production, one app at a time. A deployment_status webhook adds "deployed" to each issue timeline.
- 06
Watch it land
Discord gets a build notice, UptimeRobot keeps watching, and the public roadmap changelog gets its entry.
07 · Tools
Everything on the workbench
The websites, apps and services that show up in the flows above, grouped by what they are for.
Coding agents
Claude Code
claude.comThe primary agent CLI. Every slash command in the Hardcover repo is a Claude Code command.
- /issue, /review, /goose:pr and friends
- Non-interactive runs via claude -p
- Interactive pairing in Conductor
OpenAI Codex CLI
github.comThe backup executor. Model aliases fall back to GPT models when Claude usage windows are exhausted.
- codex exec for unattended runs
- Automatic failover when a provider hits its cap
Model aliases
hub.hardcover.appThinking, Balanced and Quick: each a ranked list of models and efforts tried in order.
- Reviews run on Thinking
- Switching models mid-run when a usage window fills
Workspaces
Conductor
conductor.buildMac app for running many agents in parallel git worktrees, each with its own ports and database.
- Human-driven development
- Opening a workspace straight from a PR link
Conductor Cloud
conductor.buildThe same workspaces, hosted. Nautilus creates them over the API and streams the session back.
- issue-N and pr-N workspaces for Jean
- review-N workspaces for Electra
- branch-N workspaces with many parallel sessions
Mac Mini host bridge
A small daemon on the Mac Mini that runs Claude Code or Codex locally when an agent is configured to run "on Nautilus".
- Cheaper, local runs
- Keychain-backed auth
Planning & tracking
GitHub Issues
github.comWhere bugs, features and tasks live. Assigning one to @jules-hardcover starts the machine.
- Bug reports
- Feature and task tracking
- Area, Priority and Code labels
GitHub Project: Hardcover Pull Requests
github.comEvery open PR, in one of six Status lanes. Bots move the first four; only humans move the last two.
- PR state
- The "Ready to Deploy" queue Adam sweeps
Hub · Products
hub.hardcover.appList of active products (features big enough to get their own board).
- Finding what is being built right now
Hub · Product timeline
hub.hardcover.appEverything that happened on one product: tasks moved, plans approved, runs dispatched, PRs opened.
- Catching up on a feature
Hub · Task board
hub.hardcover.appPer-product kanban from New to Verified. Dropping a task into "Ready to Develop" dispatches an agent.
- Writing the prompt for each task
- Research & Plan, Sign off, pick a branch
Hub · Development
hub.hardcover.appEvery agent run in flight: Queued, Running, Failed, Done, with command, model and cost.
- Retry, cancel, mark done
- Per-product branches at /products/<slug>/development
Community & feedback
Public roadmap
roadmap.hardcover.appWhat is in progress, publicly. Feature requests can be added and upvoted; a public changelog records what shipped.
- Upvoting ideas
- roadmap.hardcover.app/changelog
Hardcover Discord
discord.ggWhere the community reports bugs (#bugs and elsewhere) and where daily digests and deploy notices land.
- Bug reports
- Build notifications
- Daily summary from Nadia
Help Scout · jules@hardcover.app
helpscout.comThe support inbox. Email to jules@hardcover.app lands here; Hanson drafts a reply, a person sends it.
- Support tickets
- Bugs that become GitHub issues
- Small bugs fixed directly from the ticket
Observability
Grafana
grafana.hardcover.appLogs, metrics and traces from every project in one place (Loki, Prometheus, Tempo).
- Debugging production
- The read-only /grafana investigation command
Bugsnag
bugsnag.comError tracking for the Rails app, the React client, and the API.
- /bugsnag triages the last 24h into issues
- /bugsnag-triage fixes them
UptimeRobot
uptimerobot.comExternal uptime checks for each public service.
- Knowing when something is down before Discord does
Infrastructure
GitHub Actions
github.comCI on every PR, and the manually dispatched deploy workflows in the deployments repo.
- rspec, Rubocop, React CI, N+1 report, page budgets, migrations
- Deploy Application from Source: stage, then production
Kubernetes on DigitalOcean
github.comHelm charts and SOPS-encrypted secrets for stage and production, one app at a time.
- hardcover-rails, hardcover-api, workers, hasura, search-proxy, recommendations and more
Obsidian vault
obsidian.mdThe company knowledge base Nautilus distills into a wiki and embeds for agent retrieval.
- Decision records
- Agent context
Playwright
playwright.devHeadless browser for screenshots and walkthrough videos attached to PRs as evidence.
- /screenshot
- /pr-evidence for risk: ui changes
08 · Changelog
How the process has changed
The loop above did not arrive fully formed. Each entry is a change to how we work, not a change to the product.
-
This site
Published sdlc.adamfortuna.com to explain the process end to end, with this changelog to track how it drifts.
-
Runs switch models mid-flight
When a provider hits its usage window, a running agent is interrupted and resumed on the next model in its alias instead of failing.
-
Reviews share the author's workspace
Electra reviews a Jean PR as a second session inside the same Conductor Cloud workspace, instead of spinning up a separate one. Also decided: PR evidence, auto-rebase, and "no agent or merge ever deploys".
-
Nautilus owns agents and model routing
Agents, their model aliases, effort, location and concurrency moved from JSON files in the vault into the Hub database, editable at /agents with no deploy.
-
Waiting work is a queued Run
Work waiting for a workspace slot now shows up on the Development board as a queued Run instead of disappearing into a job queue.
-
The PR board tracks PRs only
Issues are no longer added to the Hardcover Pull Requests project. The board is purely PR state.
-
Project Status replaces PR labels
The six-lane Status field on the GitHub project became the source of truth for PR state. Electra moves cards based on her verdict; Ready to Deploy and Done stay human-only.
-
A dedicated reviewer account
@jules-hardcover-reviewer is created so the coder and the reviewer are different GitHub identities and can request each other.
-
Jules joins GitHub
The @jules-hardcover account is created: the first bot author at Hardcover.