The project session

Every feature in runcastle has its own conversation. The project session is the one that does not: a single chat per project, above the feature list, for the part that happens before a feature exists.

What it is for

The New Feature form asks for a title and a one-liner. Often you have neither. You have a complaint, a screenshot, a paragraph from a customer, or a vague sense that the settings screen is wrong. The project session takes that and grills it until it resolves into named features, then creates them.

It does three other things worth knowing about.

• Answers questions about the project. Have we already decided this? Did we ever build that? It can read the charter, the decision log, and the record of what past features actually did.
• Routes. One lump of intent has five possible destinations: a new feature, a quick change, a revisit on a feature that already exists, a fresh lap on one that went wrong, or nothing at all. Picking the right door is most of the value.
• Keeps the charter. CONTEXT.md, the project's standing decisions, is written here and nowhere else.

Opening it

Click the project row pinned above the feature list, then Talk it through. The same button appears on an empty project and inside the New Feature form, for the moment you open the form and realise you cannot fill it in.

One session is live per project. Opening it again resumes the last conversation rather than starting over, so the context you built stays.

Where it runs

In a worktree runcastle owns, on a branch called runcastle/project, never in your checkout. When you end the session its commits land on your main branch, and show up in your working copy the way a git pull would.

It is the only session allowed to edit code directly. Feature conversations write docs; this one can fix the typo you found while explaining the bug. One thing to expect: only merged features have their docs on disk there. A feature still in flight keeps its docs on its own branch, so ask about work in progress and it will tell you it cannot see it.

It cannot advance a phase, cut tickets, or start a build. A session with no feature has no business pushing one through a gate.

Drafts

Not everything you name is something you want to start. A draft is a feature parked at title, one-liner, and an optional brief. No branch is cut, no docs are written, nothing is committed, and no agent runs. It is a row in runcastle's database and a card in your sidebar.

Drafts come from two places:

• You. Save as draft sits next to the button that starts one, in the New Feature form.
• An agent. When a feature conversation turns up scope that does not belong in the feature being discussed, it parks it as a draft with a brief explaining why, instead of quietly swallowing it or losing it. Feature conversations may only park drafts. Cutting a branch is the project session's job.

Drafts sit in their own band in the sidebar, below the live work. A draft's screen shows what you parked and a Start button.

Starting a draft

Start does everything the draft skipped, in order: picks the base branch (chosen at that moment, not when the draft was saved), cuts feature/<slug>, writes the brief into the repo as brief.md, and opens the ideation session. From there it is an ordinary feature walking the pipeline.

Until you start it, everything else refuses: no sessions, no tickets, no burn, no merge. Deleting a draft deletes a row and touches nothing in git. A parked draft cannot be edited yet.