Before filing
Closest existing issue
none found (#63, which added the gated automation noun to berdctl, is the nearest precedent for extending a berdctl noun)
Is this new, or an improvement?
Improvement to the existing berdctl project commands
The problem, in your terms
A project created without a working directory can't be given one from the command line. project create --working-dir is the only place that setting is accepted — there is no equivalent for a project that already exists.
What you do today
I edited the project's state file in ~/.local/share/goose/projects/<id>.md by hand, adding the workingDirs and projectWorkspaces keys — copied from a throwaway project I created purely to learn the format, then archived. Berd picked the change up immediately and it works, but hand-editing app state clearly isn't the intended path.
What you'd like to see
Something like berdctl project set-working-dir --project-id <id> --path <path> (repeatable, ideally with a matching removal), so an existing project's folders can be managed the way its startup mode already can via project set-startup-mode.
Why this belongs in Berd itself
berdctl already exposes project create / list / get / set-startup-mode / archive. Working directories are the one project attribute that's write-once-at-creation, which leaves the noun incomplete and pushes users (and the agents driving berdctl on their behalf) toward editing state files by hand.
Non-goals
Not asking to change multi-workspace behaviour, folder attachment semantics, or anything in the UI — just CLI parity for an existing project attribute.
Alternatives you considered
Hand-editing the project markdown file (works, fragile); creating a new project with the right folder and moving all sessions into it (loses project identity/groups).
Filed via gh (an agent helped investigate and draft; I reviewed before posting). Laid out with the feature-request form's fields since the API path doesn't render the form.
Before filing
Closest existing issue
none found (#63, which added the gated
automationnoun to berdctl, is the nearest precedent for extending a berdctl noun)Is this new, or an improvement?
Improvement to the existing
berdctl projectcommandsThe problem, in your terms
A project created without a working directory can't be given one from the command line.
project create --working-diris the only place that setting is accepted — there is no equivalent for a project that already exists.What you do today
I edited the project's state file in
~/.local/share/goose/projects/<id>.mdby hand, adding theworkingDirsandprojectWorkspaceskeys — copied from a throwaway project I created purely to learn the format, then archived. Berd picked the change up immediately and it works, but hand-editing app state clearly isn't the intended path.What you'd like to see
Something like
berdctl project set-working-dir --project-id <id> --path <path>(repeatable, ideally with a matching removal), so an existing project's folders can be managed the way its startup mode already can viaproject set-startup-mode.Why this belongs in Berd itself
berdctl already exposes project create / list / get / set-startup-mode / archive. Working directories are the one project attribute that's write-once-at-creation, which leaves the noun incomplete and pushes users (and the agents driving berdctl on their behalf) toward editing state files by hand.
Non-goals
Not asking to change multi-workspace behaviour, folder attachment semantics, or anything in the UI — just CLI parity for an existing project attribute.
Alternatives you considered
Hand-editing the project markdown file (works, fragile); creating a new project with the right folder and moving all sessions into it (loses project identity/groups).
Filed via
gh(an agent helped investigate and draft; I reviewed before posting). Laid out with the feature-request form's fields since the API path doesn't render the form.