Skip to content

refactor(cli): describe each zova-ops action once in a table - #117

Merged
ata-sesli merged 2 commits into
simplify/build-source-checkfrom
simplify/zova-ops-table
Nov 3, 2026
Merged

ata-sesli merged 2 commits into
simplify/build-source-checkfrom
simplify/zova-ops-table

Conversation

@ata-sesli

Copy link
Copy Markdown
Member

Summary

Implements #112. Each zova-ops action is now described once, in a table, instead of in three separate places in cbm_cmd_zova_ops.

Stacked on #116. This PR's base is simplify/build-source-check. Review and merge #116 first; GitHub then retargets this PR to main.

Problem

cbm_cmd_zova_ops (src/cli/cli.c), the codebase-memory-mcp zova-ops <action> handler, listed its 12 actions three times:

  1. cli_zova_ops_action_known, which accepted or rejected the action name;
  2. an if/else if chain of flag rules, written as long !input && !output && … expressions;
  3. a second if/else if chain that called the matching cbm_zova_database_* or cbm_zova_workspace_* function.

Adding or changing an action meant editing all three consistently. The code graph scored the function at cognitive complexity 182; the next highest function in src/ is at 58.

Change

Two commits.

1. Characterization test (test(cli): pin zova-ops flag rules and usage-error order). The existing test only checked exit codes, and only one forbidden-flag case. The new test cli_zova_ops_flag_rules_and_error_order passes against the old code and pins:

  • for every action: its required flags pass validation; dropping any required flag, or adding any flag the action does not accept, fails with invalid flags for zova-ops action; adding an optional flag (--replace for import-workspace, --workspace-id for health) passes;
  • the reason in the JSON report for each usage error, including which error wins when several apply. For example, a missing --json is reported before an invalid --workspace-id, which is reported before an invalid --confirm-workspace.

2. Refactor (refactor(cli): describe each zova-ops action once in a table). Each row of cli_zova_ops_actions holds:

  • the action name;
  • required and optional bit masks over --input, --output, --workspace-id, --confirm-workspace, --repo-path, --confirm-replace and --replace;
  • a small wrapper that calls the Zova operation with the parsed arguments.

cbm_cmd_zova_ops now parses the flags (same parser as before), looks up the row, checks the given flags against its masks, and runs the wrapper. The function went from 104 lines to 71. cli.c is 69 lines longer overall, mostly the 12 three-line wrappers.

Behaviour is unchanged: the same usage-error messages in the same order, the same exit codes, the same JSON report, and health_classification is still only reported for health.

Verification

  • Full test suite with CBM_TEST_TIERS=all, macOS arm64: 6,449 passed, 0 failed.
  • The new test catches rule changes: temporarily allowing --repo-path on health in the table made it fail. Reverted.
  • clang-format-diff (clang-format 22.1.8) is clean on the changed lines, and git diff --check passes.
  • Not done: I did not re-measure the function's cognitive complexity in the code graph.

The existing zova-ops test checks exit codes for one valid call per
action and a few invalid ones. Before restructuring cbm_cmd_zova_ops,
pin its full behaviour against the current code:

- for every action, its required flags pass validation; dropping any
  required flag, or adding any flag the action does not accept, fails
  with "invalid flags for zova-ops action"; adding an optional flag
  (--replace for import-workspace, --workspace-id for health) passes;
- each usage error's reason in the JSON report, including which error
  wins when several apply.

Signed-off-by: ata-sesli <atasesli@protonmail.com>
cbm_cmd_zova_ops listed its 12 actions in three places: the known-action
list, an if/else chain of per-action flag rules written as long
"!input && !output && ..." expressions, and a second if/else chain that
called the operation. Adding or changing an action meant editing all
three consistently.

Each action is now one row of cli_zova_ops_actions: its name, the flags
it requires, the flags it also accepts, and a small wrapper that calls
the Zova operation. The command parses the flags, looks up the action,
compares the given flags against the row's masks, and runs it.

Behaviour is unchanged: the same usage-error messages in the same order,
the same exit codes and JSON report, and the health classification
still only reported for the health action.

Signed-off-by: ata-sesli <atasesli@protonmail.com>
@ata-sesli ata-sesli added this to the v2.1.0 milestone Nov 3, 2026
@ata-sesli
ata-sesli added this pull request to stack #120 November 3, 2026 20:14
@ata-sesli
ata-sesli merged commit e61949d into main Nov 3, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant