Dual task graphs: Fulreach (FUL) vs Mainark dogfood (MAI)

Mainark can own more than one SQLite task database. They must not share ids.

Graph	DB	Prefix	Target repo	Epics config
Fulreach product	`data/orchestrator.db`	`FUL-*`	Fulreach	Fulreach `.mainark/epics.json`
Mainark dogfood	`data/mainark-tasks.db`	`MAI-*`	Mainark	Mainark `.mainark/epics.json`

Why separate

Fulreach mainark next must not pick Mainark infra work.
Mainark PRs land on adriguerra/mainark, not Fulreach.
Status / deps / agent_runs stay clean per product.

Env switch

Fulreach (default in Mainark .env):

SQLITE_PATH=./data/orchestrator.db
MAINARK_ISSUE_PREFIX=FUL   # or omit; default FUL
MAINARK_BRANCH_PREFIX=feat/ful-

Mainark self:

cp .env.mainark-self.example .env.mainark-self
# edit MAINARK_TARGET / REPO_PATH to this repo
set -a && source .env.mainark-self && set +a
mainark queue

MAINARK_ISSUE_PREFIX (fallback: LINEAR_TEAM_KEY) controls createIssue ids via allocateIdentifier.

Phase 0 lives on Fulreach

Cloud environment work is a FUL-* issue on orchestrator.db (e.g. FUL-867), not a MAI implement target.

Programmatic Cloud Agent API findings: adr-002-cursor-cloud-agent-api.md (MAI-5).

bun scripts/create-fulreach-cursor-cloud-env-issue.ts
bun scripts/update-mainark-cloud-control-plane-frozen.ts FUL-867

A/B (MAI-3/4) run in parallel with FUL-867; only MAI-6 Fulreach e2e soft-gates on it.

Invariants (dogfood plan)

work_status=done only after merge
Agent progress on agent_runs, not issue flags
mainark ready is derived: PR exists ∧ CI green ∧ latest review attempt for that PR succeeded with verdict=PASS ∧ work_status ≠ done
Review execution status (succeeded/failed) is separate from review outcome (metadata.verdict=PASS|FAIL)
Coding agents = Cursor Cloud; Hetzner = Fulreach runtime (+ optional tiny coordinator later)