Version
BB 0.40.0 on macOS.
Reproduction
-
Create a standard project from a local Git checkout before that checkout has an origin remote. The persisted project row has gitRemoteUrl: null.
-
Later add a valid origin remote to the same default local source.
-
git remote get-url origin and the live project inspection path can derive the remote, but bb project show <id> --json continues to read the stale persisted null until the database is changed out of band.
-
There is no sanctioned repair command:
bb project update only exposes --name.bb project source update only exposes --path and --default.bb project source add --remote-url applies only to --clone; adding/updating a local source does not refresh the project remote.
A project-scoped plugin doctor that compares its configured repository target to BB-core project.gitRemoteUrl therefore fails even though the exact default source is readable and its live Git remote is unambiguous.
The affected project was repaired by its operator with a disclosed direct update to BB's database, but plugins and users should not need or be encouraged to mutate bb.db.
Expected
Provide one sanctioned existing-project mutation, for example:
bb project update <id> --git-remote <url>
bb project update <id> --refresh-git-remote
or make local default-source add/update re-derive the persisted project remote when the stored value is null.
Requirements:
- Explicit project ID; no ambient project fallback.
- Derivation reads the exact selected/default source on its owning host and fails closed when missing, unreadable, non-Git, ambiguous, or without an
origin.
- Normalize the same SSH/HTTPS repository identity forms used at project creation.
- Do not silently overwrite a non-null explicit remote merely because another source differs; require an explicit replace operation.
- Persist atomically and update project timestamps/history as ordinary BB project state.
project show, native project facts, and plugin API reads agree immediately after success.
Controls
- Null stored remote + one readable default source with
origin: refresh succeeds.
- Missing origin, multiple ambiguous sources, foreign host/source, and unreadable checkout: no mutation.
- Existing non-null remote: implicit refresh refuses; explicit replacement succeeds.
- Source path/default changes do not accidentally inherit another project's remote.
This is BB-core state ownership; plugin fallback to live inspection can improve diagnostics but cannot repair the stale native project fact.
Version
BB
0.40.0on macOS.Reproduction
Create a standard project from a local Git checkout before that checkout has an
originremote. The persisted project row hasgitRemoteUrl: null.Later add a valid
originremote to the same default local source.git remote get-url originand the live project inspection path can derive the remote, butbb project show <id> --jsoncontinues to read the stale persisted null until the database is changed out of band.There is no sanctioned repair command:
bb project updateonly exposes--name.bb project source updateonly exposes--pathand--default.bb project source add --remote-urlapplies only to--clone; adding/updating a local source does not refresh the project remote.A project-scoped plugin doctor that compares its configured repository target to BB-core
project.gitRemoteUrltherefore fails even though the exact default source is readable and its live Git remote is unambiguous.The affected project was repaired by its operator with a disclosed direct update to BB's database, but plugins and users should not need or be encouraged to mutate
bb.db.Expected
Provide one sanctioned existing-project mutation, for example:
or make local default-source add/update re-derive the persisted project remote when the stored value is null.
Requirements:
origin.project show, native project facts, and plugin API reads agree immediately after success.Controls
origin: refresh succeeds.This is BB-core state ownership; plugin fallback to live inspection can improve diagnostics but cannot repair the stale native project fact.