From 8254fb91a92ae4a297ed536f8dac6145caa55372 Mon Sep 17 00:00:00 2001 From: Jakub Zych Date: Wed, 30 Sep 2026 22:16:51 +0200 Subject: [PATCH] docs(11.1-03): log the bonfire duplicate command name gap as a todo --- .../todos/pending/bonfire-duplicate-command-names.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 .planning/todos/pending/bonfire-duplicate-command-names.md diff --git a/.planning/todos/pending/bonfire-duplicate-command-names.md b/.planning/todos/pending/bonfire-duplicate-command-names.md new file mode 100644 index 0000000..b1ee784 --- /dev/null +++ b/.planning/todos/pending/bonfire-duplicate-command-names.md @@ -0,0 +1,12 @@ +--- +title: Reject duplicate console command names in bonfire.NewRoot +date: 2026-09-30 +priority: low +area: summercms.go bonfire +--- + +`bonfire.NewRoot` validates each command name's form (`namespace:verb`, or one of the bare framework names) but does not check for duplicates. The generated application `main` appends plugin commands after the framework's runtime commands, so a plugin that declares a command with the same name as a framework command, or as another plugin's command, builds and starts without an error, and which one runs is decided by Cobra. + +Found while writing `docs/console/writing-commands.md` (Phase 11.1 plan 03). The page describes the current behaviour: names are not checked for duplicates, so keep commands in the plugin's own namespace. + +Suggested fix: make `bonfire.NewRoot` fail with an error naming the duplicated command when two commands share a name. `bonfire.NewCatalog`, which the scheduler calls through, has no error return, so the generated `main` should build the root first (as it does today) and rely on that check. Update the bonfire README and the docs page in the same change (the D-13 docs rule). The API change is outside the docs phase boundary, so it is not made in Phase 11.1.