Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions LOGIC.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,7 @@ The Framework: autonomous AI programming. The user registers repositories as pro
- `packages/agent-driver` β€” the driver [2] seam: one contract for driving a coding agent as a black box, with the Claude Code, Codex, GitHub Actions and fake implementations; the product adds its own cloud-session implementation behind the same contract. The Framework prompts one turn at a time, lets the coding agent's own loop run to completion, and learns everything from the turn's final message: it never gates on the agent's individual tool calls, holds no model key, and runs on the user's own subscription.
- `packages/agent-data` β€” a branch of the project's repository used as a file store: the `agent-data` branch [6], checked out under `.branches/`, written through one sync β†’ commit β†’ push cycle that re-applies when a push loses a race. A library, not a skill: read by code, never by an agent. Every skill depends on it; nothing else does.
- `packages/skill-branches`, `packages/skill-tickets`, `packages/skill-queue`, `packages/skill-logs` β€” the four skills [8]: an agent's own checkout [3] and branch; the tickets with their plans and claims; the agent queue [7]; the record of every run [18]. Tickets, queue, runs and routine locks live on the `agent-data` branch, never on a code branch, so the default branch stays code only. No skill depends on another.
- `packages/routines` β€” the routines the daemon fires on its own, one skill file each and no code: jobs that compose the four skills [8], starting with the queued work; The Framework depends on it and fires a routine by its slash command.
- `packages/chrome-extension` β€” the far end of the Claude web bridge [14], a Chrome extension reading claude.ai in a signed-in browser; it talks to the daemon over HTTP only.
- `packages/the-framework.ai` β€” the marketing site at https://the-framework.ai; it presents the product and shares no code with it.
- `.github/workflows` β€” every push builds, type-checks and tests the monorepo; the website deploys itself from the default branch; and one workflow is the far end of the `github-actions` driver implementation, running one turn per workflow run.
Expand Down
1 change: 1 addition & 0 deletions packages/LOGIC.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ The deliverables The Framework ships, one directory each. The product is the `fr
- **The `tickets` skill** (`skill-tickets/`) - the `@gemstack/skill-tickets` npm package: the project's tickets with their plans and claims on the `agent-data` branch, the `tickets` command that reads, writes, claims and closes them, and the skill text. Depends on `agent-data`.
- **The `queue` skill** (`skill-queue/`) - the `@gemstack/skill-queue` npm package: the agent queue on the `agent-data` branch, the `queue` command that reads it, adds an entry at a priority and takes one off, and the skill text. Depends on `agent-data`.
- **The `logs` skill** (`skill-logs/`) - the `@gemstack/skill-logs` npm package: the record of every run agents made on a project, on the `agent-data` branch, and the read-only `logs` command; the product writes every run through it. Depends on `agent-data`.
- **The routines** (`routines/`) - the `@gemstack/routines` npm package: the jobs a daemon fires on its own, one skill file each under `skills/<name>/` and no code, each composing the capability skills of a project; the queued work first.
- **The Claude web bridge's extension** (`chrome-extension/`) - a Chrome extension, not an npm package: the far end of the Claude web bridge [5], reading claude.ai in a signed-in browser. Talks to the product over HTTP only.
- **The website** (`the-framework.ai/`) - the marketing site at https://the-framework.ai. Presents the product; shares no code with it.

Expand Down
10 changes: 5 additions & 5 deletions packages/framework/dashboard/components/AiQueue.LOGIC.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ The Overview's [1] "AI Queue" card: every project's open queue entries [2], grou

**User story**: the user opens the Overview, reads under "AI Queue" what the agents will pick up next in each project, clicks a ticket's title to read it, presses play on one entry to have it worked now, or sets "3" and presses the fan-out button to start three agents on a project's top three entries.

**Business logic story**: the daemon's drain [6] half of Auto PM [7] starts an agent on the agent queue's first open entry on its own clock; this card is the same work started on the user's click, so an agent started here runs exactly the way a drained one does.
**Business logic story**: the queued work [6] half of Auto PM [7] starts an agent on the agent queue when the `agent-data` branch moves; this card starts an agent on one named entry on the user's click, and it runs the way the daemon's agent does: unattended.

## Glossary

Expand All @@ -13,8 +13,8 @@ The Overview's [1] "AI Queue" card: every project's open queue entries [2], grou
[3] agent: the unit of work: one task worked by a coding agent under The Framework's control β€” in its own checkout, on its own branch, streaming events, handed off when it ends. Started from the dashboard by the user, or by the daemon.
[4] fan-out: starting several agents at once, one per queue entry or one per ticket to plan.
[5] launcher: project home is a project's own page with the launcher (the Start form) and its composer (the prompt editor, also used for live chat).
[6] drain: starting an agent on the agent queue's first open entry β€” the half of Auto PM that spends existing work.
[7] Auto PM: the daemon's unattended product management: drain the agent queue, and refill it by running the routines.
[6] the queued work: the routine that spends existing work: one agent started with `/work-queue` when the `agent-data` branch moved, which takes one task off the agent queue by composing the skills in its checkout.
[7] Auto PM: the daemon's unattended product management: work the agent queue when the `agent-data` branch moves, and refill it by running the routines.
[8] prompt agent: a prompt agent runs one prompt and stops there.
[9] unattended: said of an agent nobody is watching: its gates take the recommended option and it ends when its work settles.
[10] skill: one of the four capabilities an agent is taught β€” `branches`, `tickets`, `queue`, `logs`.
Expand Down Expand Up @@ -56,7 +56,7 @@ Each row prints the entry's title rather than its source: the text of a link at

#### Context

**User story**: the user presses play on "Improve tooltip…" and watches one agent [3] implement that entry, as the drain [6] sweep would have, but now.
**User story**: the user presses play on "Improve tooltip…" and watches one agent [3] implement that entry, now.

#### Business logic

Expand All @@ -66,7 +66,7 @@ The play button, named "Spin up an agent working on this entry", starts a prompt

#### Context

**Problem**: several agents told "work the first open entry" would all implement the same one; a batch must pin each agent to its own entry, the way the daemon's drain [6] batch does.
**Problem**: several agents told "work the first open entry" would all implement the same one; a batch must pin each agent to its own entry, the way the daemon's plan fan-out does.

#### Business logic

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ The Overview [1], the dashboard's landing page shown while no project is selecte
[2] quota: the account's subscription allowance, as the coding agent reports it: a session window and a quota week, each with a percentage used.
[3] intervention: something that needs a human β€” an open question, a pull request to review, unpushed commits β€” one of the two notification feeds.
[4] agent: the unit of work: one task worked by a coding agent under The Framework's control β€” in its own checkout, on its own branch, streaming events, handed off when it ends.
[5] routine: a preset the daemon fires on its own on a schedule β€” update tickets, triage quick, triage consensual, plan tickets, maintenance β€” each switchable off and runnable on demand.
[5] routine: a job the daemon fires on its own β€” the queued work, update tickets, triage quick, triage consensual, plan tickets, maintenance β€” each switchable off and runnable on demand.
[6] gate: a question with options at which an agent stops and waits for an answer: it emits the question in its turn's final message, the dashboard shows it as a card, and the answer re-prompts the agent.
[7] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.

Expand Down
2 changes: 1 addition & 1 deletion packages/framework/dashboard/components/DashboardPage.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ export function DashboardPage({
that fires one now. */}
<RoutineWork onAgentStarted={onAgentStarted} onSelectProject={onSelectProject} />

<HotTickets onSelectProject={onSelectProject} onSelectAgent={onSelectAgent} />
<HotTickets onSelectProject={onSelectProject} />
</div>
</ScrollArea>
)
Expand Down
17 changes: 8 additions & 9 deletions packages/framework/dashboard/components/HotTickets.LOGIC.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in three lanes β€” "In progress", "AI Queue" and "High priority" β€” re-read every 10 seconds, where selecting a ticket opens the agent [2] implementing it, or its project's launcher [3] with the composer [4] prefilled to work on that ticket. Which tickets qualify and which lane each sits in is the daemon's decision (the lane rules in `src/dashboard/overview.ts`); the card shows every ticket it is given, never a "+N more".
The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in three lanes β€” "In progress", "AI Queue" and "High priority" β€” re-read every 10 seconds, where selecting a ticket opens its project's launcher [3] with the composer [4] prefilled to work on that ticket. Which tickets qualify and which lane each sits in is the daemon's decision (the lane rules in `src/dashboard/overview.ts`); the card shows every ticket it is given, never a "+N more".

## Context

**User story**: from the Overview [1] the user sees at a glance, across every project, which tickets an agent [2] is implementing or has planned, which sit on the agent queue [5] for the daemon to pick up on its own, and which are flagged high priority; one click takes them to the agent working a ticket, or to a launcher [3] ready to start an agent on it.
**User story**: from the Overview [1] the user sees at a glance, across every project, which tickets an agent [2] has planned, which sit on the agent queue [5] for the daemon to pick up on its own, and which are flagged high priority; one click takes them to a launcher [3] ready to start an agent on it.

## Glossary

Expand All @@ -12,13 +12,12 @@ The Overview's [1] "Hot tickets" card: a cross-project shortlist of tickets in t
[4] composer: the prompt editor on a project's own page, also used for live chat.
[5] the agent queue: `TODO_AGENTS.md` on the `agent-data` branch: every task agents will work next, in priority sections, worked top-down.
[6] preset: a canned prompt the user launches from the dashboard.
[7] drain: starting an agent on the agent queue's first open entry β€” the half of Auto PM that spends existing work.

## Business logic β€” TL;DR

- **Three lanes in two columns** - "In progress" and "AI Queue" stack on the left, "High priority" stands alone on the right; each lane's header carries a colored dot, its label and its count, and an empty lane dims to its header.
- **Every ticket, with its one tag** - a row shows the ticket's title, at most one tag ("implementing" in the accent color, else "planned", else the priority value) and its project's name; the tooltip shows the ticket's summary.
- **Selecting a ticket** - a ticket an agent is implementing opens that agent; any other ticket opens its project's launcher with the composer prefilled "Work on tickets/<file>. Do not start any other ticket."
- **Every ticket, with its one tag** - a row shows the ticket's title, at most one tag ("planned", else the priority value) and its project's name; the tooltip shows the ticket's summary.
- **Selecting a ticket** - opens its project's launcher with the composer prefilled "Work on tickets/<file>. Do not start any other ticket."
- **Empty says what is empty** - with no hot ticket at all the card reads "Nothing in progress, queued, or high priority." rather than claiming there are no tickets.

## Business logic
Expand All @@ -37,21 +36,21 @@ The card is titled "Hot tickets" with a flame icon. The tickets are re-read from

#### Context

**Problem**: a lane that holds both a ticket being coded as the user reads and a ticket someone planned at some point must say which is which; "planned" is a mark work left behind, "implementing" describes something happening now.
**Problem**: a row must say why it is in its lane, with one word.

#### Business logic

A row is a button showing the ticket's title, truncated with an ellipsis, then at most one tag, then the project's name at the right. The tag is the one fact that earns the ticket its lane: "implementing", outlined in the accent color, when an agent [2] is implementing the ticket right now; otherwise, in the "In progress" lane, "planned" when the ticket has a plan; otherwise, in the "High priority" lane, the ticket's priority value; an "AI Queue" row carries no tag, because the lane already says it. Only "implementing" is colored; the other tags are muted. Hovering a row shows the ticket's summary, or its title when it has no summary.
A row is a button showing the ticket's title, truncated with an ellipsis, then at most one tag, then the project's name at the right. The tag is the one fact that earns the ticket its lane: in the "In progress" lane, "planned" when the ticket has a plan; otherwise, in the "High priority" lane, the ticket's priority value; an "AI Queue" row carries no tag, because the lane already says it. Only "implementing" is colored; the other tags are muted. Hovering a row shows the ticket's summary, or its title when it has no summary.

### Selecting a ticket

#### Context

**Problem**: a ticket nobody is implementing has no agent [2] to jump to; landing on its project's launcher [3] with an empty composer [4] and the ticket forgotten would make the row a dead end.
**Problem**: landing on the ticket's project launcher [3] with an empty composer [4] and the ticket forgotten would make the row a dead end.

#### Business logic

A ticket an agent is implementing opens that agent's page: the daemon knows which agent recorded the ticket, and that agent is what the row reports on. Any other ticket opens its project's launcher and hands the composer the draft "Work on tickets/<file>. Do not start any other ticket." β€” plain text the user reads and edits before sending, so there is no second, hidden version of the ask; it names the ticket's file, the ticket's identity, rather than its title, which is prose the agent would have to search for. Its wording is the drain [7] preset's [6], narrowed to the one ticket. The draft is stashed for the launcher to take once on arrival (the hand-over rules in `lib/draft-handoff.ts`); opening an agent leaves no draft behind, so nothing surfaces later on an unrelated visit to a launcher.
Selecting a ticket opens its project's launcher and hands the composer the draft "Work on tickets/<file>. Do not start any other ticket." β€” plain text the user reads and edits before sending, so there is no second, hidden version of the ask; it names the ticket's file, the ticket's identity, rather than its title, which is prose the agent would have to search for. Its wording is the drain [7] preset's [6], narrowed to the one ticket. The draft is stashed for the launcher to take once on arrival (the hand-over rules in `lib/draft-handoff.ts`); opening an agent leaves no draft behind, so nothing surfaces later on an unrelated visit to a launcher.

### Empty says what is empty

Expand Down
Original file line number Diff line number Diff line change
@@ -1,10 +1,8 @@
What the tests cover, for the Overview's [1] "Hot tickets" card:

- **The empty card names its lanes** - with nothing hot it reads "Nothing in progress, queued, or high priority." rather than claiming no tickets exist.
- **Three lanes, and a click into the project** - tickets are grouped under "In progress", "AI Queue" and "High priority", and selecting a ticket no agent [2] is implementing opens its project.
- **The implementing tag outranks the plan** - a ticket an agent is implementing right now reads "implementing" while a planned ticket beside it reads "planned"; a ticket being implemented with no plan at all still gets the "implementing" tag.
- **A ticket with an agent opens that agent** - selecting a ticket an agent is implementing opens that agent's page and not the project home; a ticket with no agent opens its project and no agent.
- **The launcher is prefilled** - selecting a ticket with no agent leaves the draft "Work on tickets/<file>. Do not start any other ticket." for the launcher [3] to take; the draft names the ticket's file, not its title; selecting a ticket that opens an agent leaves no draft behind.
- **Three lanes, and a click into the project** - tickets are grouped under "In progress", "AI Queue" and "High priority", and selecting a ticket opens its project.
- **The launcher is prefilled** - selecting a ticket leaves the draft "Work on tickets/<file>. Do not start any other ticket." for the launcher [3] to take; the draft names the ticket's file, not its title.

## Glossary

Expand Down
Loading
Loading