Starting point: these 3

Bence — this is the SparkChat Project’s reply to your long message (11 Sep 2026, after “how do bots work currently?”). Not a recut. Not a card path. Not a status dump.

Your words, verbatim:

I think what I actually wanted to do was have projects that could contain bots and tasks. and then the bots could handle the tasks. and what about the waking loop for the bots, like the ideation loop (what are ideas of what Ishould I do next based on my role), a roadmap manager, manages the roadmap of the bot, what ideas can be done in parallel, what are dependent, what order should the things be done in, based on current progress and the idea list of course and other relevent context, a learning loop or mabye it's an every turn based thing that modifies skills/memories for just that bot, as well as project level stuff, etc. and then there should be a project roadmap. one bot's job would be to manage that. and the project roadmap would be kind of a source of direction for all bots in the project, so they and the human can quickly see what the plans are, and what is being worked on. I think that could be a good starting point to get those 3 components working. btw we also need a roadmap where these 3 pieces are like the first pieces we should get built. and the roadmap should look more like a roadmap. and then once we get those pieces, other ideas are adding the bots that have scope over many projects, allowing bots to ask questions from other bots or tell other bots to do something. so one way I might use the system is to add tasks and then some bot who's job would be to manage those could add it to a specific projects task list. mabye some bot even creates a new project where it could fit in and mabye every project would have a main bot who's job is to manage the roadmap based on the task list. tasks in the task list are only handled by a layer above. so either the human user or a CEO that has a scope above the project. and then the main bot would create a roadmap for getting that task accomplished. or actually mabye the same paradigm I mentioned before where there is an ideation bot. roadmap bot, implementation bot. each can have as many jobs as they want. so similar to the swarm we've mostly already set up. and the self testing and dogfooding bots, merging bots. should we diagram this and get some more advice on how we'll use this? see if you can diagram it first. launch some parallel agents to do a few twists on this plan, so how I might use the system for different projects. e.g. development on different codes bases are each their own projects, a token management bot would have a scope above all the projects, might have a personal task list project. bots will likely also be proactive so when no tasks they'll try to do whatever may be useful towards their project, or actually that would probalby be another bot who's job is to be proactive towards the goals of the project. the ceo can create projects and bots, ceo's job is probably to serve the human user as best possible. human might just talk directly with the ceo most of the time I'm not sure. project managers may also talk to the ceo first before the human is notified of some blockers, ceo probably manages a human task list and makes it all bowtied so they can make decisions as quickly as possible or do the action they need to do as quickly as possible or potentially even resolve the question from a project bot by itself. ceo might also be proactive towards the humans goals. part of the human task list might even be questions that would allow the ceo to then delegate even more work things that the human may have not even though of yet

Starting point = these 3, plus a published project roadmap

You named those 3 as the first pieces, and you also asked for a project roadmap that looks like a roadmap:

1. Ideation loop — ideas of what to do next, based on the bot’s role.
2. Roadmap manager — from the idea list + current progress: what can run in parallel, what depends on what, what order.
3. Learning — every turn or a loop; skills and memories for that bot, and for the project.

That is the first version. A card finishing is not the product.

One bot publishes shared direction

One bot publishes the project roadmap. That published plan is the source of direction for all bots in the project. You and the bots read the same thing: the plan, and what is in flight.

The published roadmap and the manager’s plan are one artifact. Not a second backlog. Not a private todo inside a specialist chat. Two sources of plan truth is how a killed item still starts.

Later — same message, not the first slice

You said “once we get those pieces.” These stay later:

• Bots with scope over many projects
• Bots that ask other bots questions, or tell other bots to do something
• A manager that files a task onto a project, or creates a new project where it fits
• Task list only handled from above (you, or a CEO above the project)
• CEO + bowtied human list (decisions and actions, fast; maybe resolve a project question without paging you)
• Token-management bot above all projects
• Personal task-list project
• Proactive-when-idle (when there are no tasks, try something useful toward the project — or a bot whose job is that)

You asked to diagram it and run usage twists — not to replace those 3 with something else.

The recut was wrong. It is parked.

A later swarm (ChatGPT + this Project) recut the first slice into a card path: accepted → Run next → running → evidence → done/failed. Ideas only suggest. Lessons only after an outcome.

That recut is not the product. You did not sign it.

You said, same evening:

the plan is not clear

why was this decided as the MVP, it doesn't sound very similar at all to what I was talking about

but look at my long message, what was I actually asking for and why is this not similar

yea make the MVP much more similar to waht I wanted

PR #12 implemented that card-path cut. It stays parked. Do not bake it. Do not treat “a card finishes” as proof. accepted → evidence → done is not the hero.

The page you should feel

One SparkChat project. Four regions on one page. You should not need Ideas / Learning / Bots tabs to use it.

Desktop: published roadmap across the top; ideation and roadmap manager side by side; learning underneath.

Phone: stack published roadmap → ideation → manager → learning. All four regions stay on the page, including when empty.

1. Published project roadmap — In flight · Next · Parallel · Blocked · Done. Order and dependencies visible. Publisher and time next to the title. This is shared direction.
2. Ideation — what this bot should do next, given its role. Refresh, add, dismiss.
3. Roadmap manager — turn the idea list + progress into parallel / deps / order. Pin, drop, or reorder. Publish writes that plan as the shared roadmap.
4. Learning — skills and memories for this bot and for this project. Every turn or Learn from this turn. Add or correct. The next ideas should use the correction.

Slices (in this order)

Slice 1 is a partial build, not the finished concept. Keep the slices in order so planning is not built against placeholder lists.

If you must open another tab to see the plan, or if the page is a Run-next card trench, the slice failed.