Preserve command provenance and reject command name collisions in build_index() #16

New issue

Closed

opened 2026-09-24 20:40:22 +02:00 by michael · 0 comments

michael commented

2026-09-24 20:40:22 +02:00

Owner

Goal

Preserve command provenance and reject command name collisions in
scanner/index.lua's build_index().

Background

Found while tracing the actual data flow for the #13 resource-scope
discussion (which module produced a given label_resource_id), not
caused by it and not dependent on it resolving first. Two independent
defects exist in build_index() today, on main as it stands:

index[cmd_name] (the top-level command entry) carries no originating
module/contribution identity at all -- only label_resource_id,
default and subcommands. Only the subcommand level attaches mod
(the required Lua module table from entry.mod), which is a
different kind of provenance than composer.lua's contribution.module
string and is not present on the command entry itself.
build_index() iterates ipairs(contributions) and writes
index[cmd_name] = {...} unconditionally. If two contributions
declare a command with the same name, the later one silently
overwrites the earlier one -- no error, no warning, the first
command's definition (and whatever it carried) simply disappears.

The second point is a real defect independent of any i18n/resource
work: Modul A: command "foo", Modul B: command "foo" silently
losing one of them is not reasonable behaviour on its own.

Scope

index[cmd_name] retains the originating contribution/module
identity, using the same stable identity composer.lua already uses
(contribution.module), not entry.mod.
A duplicate cmd_name across contributions must not silently
overwrite the earlier entry; build_index() returns a structured
daw_error/v1 instead.
Do not design a general resource-scope/provenance contract here.
The existing contribution.module string is sufficient for this fix;
any richer provenance representation is DAW/daw-modul-berhtjan-core#13's
concern, not this issue's.

Acceptance criteria

index[cmd_name] carries the originating module identity
(contribution.module), consistently with composer.lua's compose()
A command-name collision across contributions returns
nil, daw_error/v1 (new resource_id, following the file's
existing fail() pattern) instead of silently overwriting
Tests: one command's provenance survives build_index(); a
genuine collision is red before the fix and green after,
under Lua 5.1 and 5.4
fragjan code . and make test stay clean

Found during DAW/daw-modul-berhtjan-core#13 (resource discovery/
collection design); fix this first, then continue #13 with both the
compose()/fields path and this build_index()/commands path on the
same provenance footing.

## Goal Preserve command provenance and reject command name collisions in scanner/index.lua's build_index(). ## Background Found while tracing the actual data flow for the #13 resource-scope discussion (which module produced a given label_resource_id), not caused by it and not dependent on it resolving first. Two independent defects exist in build_index() today, on main as it stands: - index[cmd_name] (the top-level command entry) carries no originating module/contribution identity at all -- only label_resource_id, default and subcommands. Only the subcommand level attaches `mod` (the required Lua module table from entry.mod), which is a different kind of provenance than composer.lua's contribution.module string and is not present on the command entry itself. - build_index() iterates ipairs(contributions) and writes `index[cmd_name] = {...}` unconditionally. If two contributions declare a command with the same name, the later one silently overwrites the earlier one -- no error, no warning, the first command's definition (and whatever it carried) simply disappears. The second point is a real defect independent of any i18n/resource work: `Modul A: command "foo"`, `Modul B: command "foo"` silently losing one of them is not reasonable behaviour on its own. ## Scope - index[cmd_name] retains the originating contribution/module identity, using the same stable identity composer.lua already uses (contribution.module), not entry.mod. - A duplicate cmd_name across contributions must not silently overwrite the earlier entry; build_index() returns a structured daw_error/v1 instead. - Do not design a general resource-scope/provenance contract here. The existing contribution.module string is sufficient for this fix; any richer provenance representation is DAW/daw-modul-berhtjan-core#13's concern, not this issue's. ## Acceptance criteria - [ ] index[cmd_name] carries the originating module identity (contribution.module), consistently with composer.lua's compose() - [ ] A command-name collision across contributions returns nil, daw_error/v1 (new resource_id, following the file's existing fail() pattern) instead of silently overwriting - [ ] Tests: one command's provenance survives build_index(); a genuine collision is red before the fix and green after, under Lua 5.1 and 5.4 - [ ] fragjan code . and make test stay clean ## Related Found during DAW/daw-modul-berhtjan-core#13 (resource discovery/ collection design); fix this first, then continue #13 with both the compose()/fields path and this build_index()/commands path on the same provenance footing.

michael added the

labels

2026-09-24 20:40:22 +02:00

michael referenced this issue from a commit