Proposal: AI-led Project governance, unified board and Handoff-driven Workflow (five-stage plan) #1550

Vision and two fundamental changes

FlyBot should become an AI-led Project Workspace. AI runs the project day to day; humans govern the rules, resolve consequential decisions, contribute proposals, and receive accountable results.

1. Project owns one unified Tasks board and the participating humans, AI roles, workflows, resources, and durable project knowledge. Opening a Project goes directly to its board (task pools, each task's current workflow/handoff, project Bot health, attention needed, recent deliveries).
2. Workflow changes from mandatory DAG orchestration to policy-based Handoff between role task pools. A Workflow is a persistent AI collaboration team; strict DAG and guards remain available where ordering is essential.

This is a design/roadmap proposal, not an implementation-ready ticket. Resolve the shared data/runtime contract before splitting development issues. Reuse existing mechanisms instead of introducing parallel boards or schedulers.

Product and governance model

Project and role-specific UI

• Owner (one per Project): ultimate governor for mission, governance policy, roles/membership, project Bots, compute/resources, budgets and autonomy boundaries. Owner's console may be detailed (Tasks/Workflows/Bots/Resources/Members/Project State/RSI); Owner normally does not manage daily tasks.
• Maintainers: make operational decisions and decide roadmap/architecture matters under governance policy; their UI emphasizes project board, decisions, meetings and deliveries.
• Members: submit issues/proposals, discuss and contribute, without default approval rights; simple project board and project assistant.
• Chief: project-owned AI manager, plans and routes work, classifies decision severity, organizes discussions and execution, escalates exceptions; not the ultimate authority.
• Project Assistant (one user–Project relationship): user's agent in this Project; holds user+project-scoped memory, can follow up on commitments, represent authorized preferences in Chief-convened meetings, and ask the human when beyond mandate. Every day at 09:00 in the user's timezone, sends a summary of the previous 24h and clear decisions requiring that person's input (with configurable delivery/quiet rules). Personal memory stays in FlyBot's own storage, never the source repository. The assistant may optionally connect the user's own GitHub account (via explicit per-user authorization), so proposals, issue comments and other contributions made on the user's behalf can be attributed to that person's GitHub identity. The assistant must distinguish user-approved/authorized actions from project-bot automation and preserve an audit trail.

Each user sees one Project board, with progressively exposed details. Workflow remains visible, not buried: it displays team roles, pool backlogs, worker activity, exceptions, handoff rules and outcomes; advanced controls need not burden Member UI.

Decision contract

Chief classifies each proposed decision and records the classification and rationale:

• Ordinary: one Maintainer's approval can conclude it.
• Major (e.g. substantial roadmap or architecture change): consensus among participating/required Maintainers under an explicit participation rule; unresolved objections trigger internal discussion, not silent approval.
• Severe (e.g. credible security/data-loss/irreversible-impact risk): a substantive minority objection pauses the risky action for review; it is a minority-protection/veto-on-risk rule, not automatic authority to impose an alternative. Owner-defined escalation/resolution rules apply.
• Owner establishes/changes supreme governance rules and resolves matters reserved to that authority.
• Maintainers can challenge Chief's classification and request reclassification. An LLM label alone never confers or bypasses GitHub/FlyBot authorization. All decisions are recorded with participants, evidence, dissent, version and resulting actions.

AI identities and authorization

Chief and Project Bots belong to the Project, not a human account. Start with a project-authorized GitHub App installation shared for repo operations, plus separate FlyBot Bot/Role/Task identities and auditable authorization checks. Avoid personal tokens for unattended project execution. A shared App does not imply independent native GitHub approval identities; maintain independent review attestations and observe protected branch/required human checks. Use minimum GitHub permissions. Revisit multiple Apps only if real identity/permission constraints require them. Personal Project Assistants are different: they may use their human user's individually authorized GitHub identity for user-attributed proposals, issue discussions and contributions. The assistant must never use the shared Project App to impersonate a user, nor borrow the user's authorization for autonomous project-Bot actions. Scope permissions and consent to the specific action; GitHub-native authorship follows the actual credential type and API operation, so verify attribution in integration tests.

Project State (minimal first version)

Store shared durable knowledge in the designated Project source repository, using existing file practices:

• PROJECT.md: mission, owner/maintainer roles (or references), repo/resources links, governing boundaries.
• ROADMAP.md: current initiatives, milestones and priorities.
• AGENTS.md and existing docs/: operational rules, architecture and standards (reuse, don't duplicate).
• decisions/: concise dated meeting/design decisions, evidence, objections, status and links to resulting tasks.
• LESSONS.md: observed failures and learning; reuse the existing lesson→validated standard promotion mechanism.

Task/queue/worker runtime state, approval/reminder state, user GitHub connection/authorization metadata and Project Assistant private memory stay in FlyBot storage. GitHub issues, PRs and CI remain their authoritative sources. A shared context reader presents current relevant versions to Chief and ephemeral workers; do not indiscriminately inject all files into every context. Record changes with provenance. Use repo review/approval rules for sensitive state edits.

Workflow and execution contract

• Durable Bot Role defines skills, tools, policies and reusable project knowledge; Task Pool holds ready work for a role within a Workflow; ephemeral isolated Bot Instance claims one executable task with task-scoped context and resource quota.
• A user-facing parent Task retains stable identity across execution. Handoffs may create linked role-specific execution tasks (or other transitions once the contract is agreed) and preserve task lineage, prerequisites, result artifacts, acceptance criteria and verification.
• After execution, a Bot proposes an action to a single authoritative Task/Handoff API; the system validates destination, authorization, required evidence, concurrency, idempotency, retries/cycles and resource limits before enqueueing. Receiver claims asynchronously; no Bot writes another role's pool without checks.
• Handoff supports fan-out, return-to-upstream, follow-up work, failure and escalation. DAG/guards remain an optional strict execution policy for release, approvals and other ordered processes.
• Normal uncertainty is resolved locally by the role or routine handoff. Cross-role disagreement, repeated failures, unclear ownership or policy gaps escalate to Chief, who may convene a temporary meeting of Bots, Maintainers and authorized Project Assistants. Archive a structured decision and create linked execution tasks. A meeting is not itself a permanent Workflow.
• Differentiate live execution messages from human-facing conversation; do not leak ephemeral Bot replies into Chief's chat. Keep recoverable, auditable task state across failures and restarts.

Existing code to build upon

• core/src/client/kanban.js: per-Bot/group board, task columns and subtasks.
• core/src/host/task-drive.js: task wakeups, queue role claims and WIP constraints.
• core/src/shared/workflow.js, core/src/shared/workflow-run.js, core/src/host/workflow-store.js: graph/guard workflow definition and task-node runtime.
• plugins/workflow/src/service.js: live run queue/concurrency and ephemeral node Bots.
• plugins/workflow/src/match.js: explicit/trigger-based routing.
• Repo AGENTS.md and LESSONS.md: operating contract and experience-to-standard practice.

A prerequisite to reworking dispatch is clarifying how core Workflow and the Workflow plugin converge on one task identity and execution lifecycle.

Five-stage roadmap (Stages 1–4 implementation direction; Stage 5 research placeholder)

Stage 1 — Run FlyBot development as an AI-governed Project (dogfood first)

Objective: prove project governance and decisions with existing Bots, Tasks, groups and GitHub, before rebuilding the interface or engine.

Scope: designate Owner/Maintainers; publish minimal governance rules; configure Chief's severity triage and escalation; convene temporary discussions using existing groups; store formal decisions and link follow-up Issues; initialize lightweight Project State files.

Acceptance: use this proposal (#1550) or a comparable real major design issue to demonstrate proposal → Chief classification/research → Maintainer discussion and consensus → archived decision → executable Issues. No PR for the architecture proposal before authorization. Include a disagreement/reclassification case. Capture what Chief could automate and what still needed human intervention.

Stage 2 — Project as the work and knowledge boundary

Objective: give the already-running organization a unified Project view without duplicating task stores.

Scope: Project identity and repository binding, task affiliation and unified board; role-aware Owner console vs Maintainer/Member views; show task/workflow/bot status, exceptions and recent verified deliveries; shared Project State context reader; adapt existing Bot/group task boards as filters. Project Assistant initially may be a limited user–project identity with private memory, optional per-user GitHub connection for attributable contributions, and on-demand summaries.

Acceptance: one Project shows tasks originating from Bot, group and Workflow in a single board with stable identities and consistent statuses; Owner can reach members, Bots, resources and governance controls; non-owners cannot perform those operations. State changes in repository are versioned and do not silently overwrite decisions.

Stage 3 — Handoff-controlled Workflow and isolated pool workers

Objective: enable independent role pools and dynamically handed-off task execution, preserving strict DAG as an option.

Scope: agree typed Task/Handoff contract; one source of truth for task progress; role queues, isolated ephemeral worker instances, quotas and lease/recovery semantics; branching and rework; evidence and audit trail. Reconcile core and plugin workflows incrementally behind the shared task contract.

Acceptance: real issue → Dev → Review → Test with independently claimed tasks; review rejection sends tracked rework; concurrent tasks do not share worker state; restart/retry doesn't produce duplicate downstream work; strict release DAG still passes regression tests; measurable accepted deliveries and resources.

Stage 4 — Chief meetings and Project Assistants in live collaboration

Objective: solve exceptional work without manually programming workflow branches; minimize burden on humans.

Scope: Chief triggers temporary AI/human meetings for unresolved issues; participants include authorized users' Project Assistants; archive decision with dissent/evidence/owners and generate linked tasks; maintain each assistant's private FlyBot-side memory; schedule personalized daily 09:00 project digests and actionable decisions, with opt-out/quiet/authorization controls.

Acceptance: an ambiguous architecture conflict escalates, meeting reaches a governance-valid outcome or remains explicitly blocked, produces archived decisions and downstream tasks. Two users receive different personalized digests derived from the same factual project status without revealing one another's private memory.

Stage 5 — RSI / autonomous project evolution (reserved; design pending)

Objective: reserve the direction of optimizing Workflow efficiency and project evolution, without committing to a specific RSI mechanism or implementation now.

Scope and acceptance criteria are TBD after separate research and design review. Candidate topics include evaluation evidence, safe experiments and rollback, evolution of Handoff rules and next-goal selection. These are research questions, not approved implementation requirements.

Gate: do not start Stage 5 development, assign it to the agent queue, or claim performance gains until a separate proposal defines the optimization objects, evaluation criteria, safety boundaries, experiments and measurable acceptance tests. Stages 1–4 should collect reliable task/artifact/handoff/decision provenance that may later support RSI.

What we are not doing in the first stage

No complete new UI, no broad rewrite of the existing DAG engine, no second board or scheduler, no big knowledge graph/vector-memory platform, no autonomous mission changes and no unreviewed privilege expansion. Track measured outcomes; treat efficiency/scalability/RSI as hypotheses to verify.

Example target end-to-end

Member raises a Proposal → Chief classifies and researches → Maintainers discuss (and may involve their Project Assistants) → a governance-valid decision is saved in decisions/ and Roadmap updated → Chief emits linked Tasks → role pools claim them in isolated Bot instances and hand off with verified artifacts → Chief escalates unforeseen conflicts via meetings → Project board displays progress and deliveries → assistants report actionable summaries; later RSI experiments compare and improve the operating policy.

Decision requested from the community

Approve the target product model and the five-stage sequence, beginning with Stage 1 dogfooding. This issue should remain a design proposal / human decision item until the governing Owner/Maintainers approve scope and split each implementation stage into reviewable tasks.