Skip to content

Stage 2.1: Project identity and repository binding (a Project record in FlyBot storage) #1691

Closed

Description

@Birfy

Written-by: Chief
Part of #1550, Stage 2 first slice. Authorization: the owner instructed on 2026-10-29 to carry #1550 through Stages 1-4; that is the approval this slice runs under, so the "no new configuration keys, no new UI" admission line does not exclude it. Scope stays inside Stage 2 as #1550 writes it.

Why this slice first

Everything else in Stage 2 needs an object to hang off: the unified board, the role-aware views, the Project State reader and the Project Assistant all have to answer "which Project is this?". Today there is no such record — groups, Bots and workflow runs exist without an owner, a repository or a scope.

What to build

The smallest durable Project identity, in FlyBot storage (never in the source repository):

  • A record with: id, name, repository (owner/name), default branch, owner user id, created/updated timestamps, and a status.
  • Create / read / list over the existing api/bot channel, following the shape of the handlers already in core/index.js and core/src/host/store.js.
  • A binding: a group and a Bot can name the Project they belong to, and a workflow run reports the Project it serves. One Project may have many members; a member belongs to at most one Project.
  • Reading is safe with no Project at all: an install with zero Projects keeps behaving exactly as today.

Acceptance

  • Tests in core/test/ cover: create + read + list; two Projects do not alias; a binding resolves back to its Project; an unbound Bot/group/run reports null instead of failing.
  • The storage survives a restart (whatever persistence the existing store uses).
  • npm run verify green at the tip (TZ=UTC); core/client.js regenerated only if core/src/client/ changed.
  • A subsystem doc under docs/subsystems/ describes the Project record and its bindings — or a valid Docs-not-needed: trailer says why not, in both the branch commit and the PR body.
  • PR body: Part of #1550, Fixes #<this issue>, Owner: Chief, Reviewer: Reviewer, checkpoint block.

Out of scope

No UI, no unified board reading, no Assistant, no change to how tasks are stored. Those are the next slices.

Activity

  1. Birfy commented on Oct 29, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Triage

    Label set: agent-ready (no previous state label to remove).

    Design conflict resolved: the owner approved the five-stage direction on 2026-10-29 (decisions/2026-10-29-stage-1-approved.md, and the #1550 comment at 11:32Z), Stage 1's first slice #1680 has landed, and #1550's Stage 2 scope names "Project identity and repository binding" first. Nothing in main today carries a Project record (code search for projectId: 0 hits), so this duplicates no existing work, and no open PR or issue claims this slice.

    Scope for the implementer:

    • Durable Project record in FlyBot storage, never in the source repo: id, name, repository (owner/name), defaultBranch, ownerUserId, createdAt, updatedAt, status.
    • Create / read / list over the existing api/bot channel, following the handler shape in core/index.js and the store pattern in core/src/host/store.js.
    • Binding field projectId on group, Bot and workflow-run records: one Project may hold many members, a member belongs to at most one Project; a workflow run reports the Project it serves.
    • Zero Projects keeps today's behaviour: an unbound group/Bot/run resolves null, never throws.

    Tests, red first (core/test/): create + read + list; two Projects do not alias; each binding resolves back to its Project; an unbound group/Bot/run returns null; the record survives a re-open of the store on the same data dir.

    Acceptance: TZ=UTC npm run verify green at the tip; core/client.js regenerated only if core/src/client/ changed; a page under docs/subsystems/ describes the record and its bindings, or a valid Docs-not-needed: trailer in both the branch commit and the PR body; PR body carries Part of #1550, Fixes #1691, Owner: Chief, Reviewer: Reviewer and the checkpoint block.

    Risk: the diff adds a persistent record plus new api/bot handlers, with no UI and no secrets/auth surface — expect T2, so a PASS at the tip from the Reviewer is needed. Quote the risk-tier: line of the job summary at PR time; never hand-write a risk:T* label.

  2. added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 29, 2026
  3. self-assigned this
    on Oct 29, 2026
  4. added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 29, 2026
  5. Birfy commented on Oct 29, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Dev

    Claimed #1691 — first step: the Project record and its store shape in core/src/host/store.js. Branch: dev/1691-project-record.

  6. removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 29, 2026
  7. removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:automationScheduled tasks and automationenhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions