feat(config): add config clone to duplicate a configuration whole

[padak]

Closes #587 (remainder — the schema-validation bug was #589, already merged).

The problem

There was no way to copy a configuration, so people rebuilt the body from config detail output — typically copying configuration["parameters"] and nothing else. A configuration's root also carries storage, runtime and authorization, and dropping one is silent: the reporter lost runtime.parallelism, Keboola fell back to parallelism: 1, and a 65-row Snowflake writer ran strictly sequentially — 140 minutes instead of the expected 60-90, caught only by hand-comparing per-row job timestamps afterwards.

The fix

kbagent config clone --project P --component-id C --config-id ID --name N [--target-project P2] [--set PATH=VALUE ...] [--secret PATH=VALUE ...] [--dry-run]

Two paths, split by encryption — not an arbitrary design choice:

Same project (default): server-side copy via POST .../configs/{id}/versions/{v}/create. Nothing is rebuilt. Verified live against a real project: a 2-row source with a runtime sibling produced a 2-row clone carrying runtime.parallelism intact. --set PATH=VALUE is applied afterwards as a normal update on the copy, so an override can never be why a key went missing.

Cross project (--target-project): reassembled client-side, rows recreated one by one — because a Keboola ciphertext is scoped to the project it was encrypted in; copying it verbatim would produce a configuration that looks complete and fails at runtime, in a project nobody is watching. Any KBC:: value — in the parent body or in a row (rows[N].path) — makes the clone fail fast (exit 5), listing every affected path, until re-supplied via --secret PATH=VALUE (encrypted in the target project on write). --dry-run reports the same paths in missing_secrets instead of refusing, which is how you discover what to gather.

Storage bucket/table IDs are copied verbatim, never remapped — sync clone is the command that does that; duplicating it here would be scope creep.

Structure

New services/_config_clone.py (not config_service.py, which make loc-check already flags as over its per-layer budget). New commands/_config_clone_cmd.py for the same reason on the commands side — mirrors the existing commands/_storage_snapshots.py pattern. KeboolaClient.create_config_copy is the one new client method.

Testing

• 15 service tests (both paths, encrypted-value refusal at parent AND row level, row copying, client selection). Mutation-tested: disabling encrypted-value detection or row copying each fail exactly the tests that claim to cover them.
• 9 CLI tests, including the human-output renderer. A first live run crashed on a human_formatter arity bug (lambda taking 1 arg instead of 2) that no service test could catch; re-introducing that bug fails 6 of the 9 CLI tests.
• E2E step 19d: clones a config carrying a runtime sibling and two rows, asserts both survive.
• make check: 5591 passed, 12 skipped.

Docs

CLAUDE.md, context.py (AGENT_CONTEXT), commands-reference.md, gotchas.md, keboola-expert.md (had to trim ~90 bytes elsewhere to stay under its 62000-byte cap). Version bumped to 0.85.0 with a full changelog entry.

Review

@zajca — could you take a look at this one specifically? The cross-project path (encrypted-value detection + refusal + row-by-row recreation) is the part I'd most want a second pair of eyes on.

---

[devin-ai-integration]

Devin Review found 9 potential issues.

View 1 additional finding in Devin Review.

[zajca]

Changes requested based on the completed review findings.

[padak]

@zajca — review findings addressed in edcb35e, all nine threads replied to and resolved. Summary of what actually changed, since three of them were real defects rather than style:

The blocking one was real and I had missed it. A re-supplied row secret (--secret 'rows[0].parameters.#token=…') was applied to the parent body, not the row. The refusal check accepted the path, set_nested_value created a literal "rows[0]" key in the parent, and the copied row kept the source project's undecryptable ciphertext — while the command reported success. That is exactly the failure this command exists to prevent, and it would only have surfaced at runtime in the other project. My own test for row secrets only covered detection via --dry-run, never application, which is why it passed.

Two more that would have leaked or crashed:

• --set 'parameters.db.#password=…' on the same-project path bypassed the Encryption API entirely and wrote plaintext to Storage (kept in version history). Repointing a copy at another database is the documented use case, so this was live traffic. Both paths now encrypt.
• Ciphertext under a plain non-# key: I verified that a supplied replacement was not picked up by collect_secrets, so it reached the target project in the clear. Those paths are now refused outright rather than accepted, pointing at kbagent encrypt values + --set instead.

Also fixed: list-element secret paths were emitted as parameters.values.[0].#token, which raises ValueError when fed back — so the CLI was refusing the clone with an instruction that then crashed. Cross-project now inherits the source description; --target-branch is rejected on a same-project clone instead of silently writing to the source branch; a row failing mid-copy reports the created config id and how many rows landed.

Two process points you were right to flag via the review: I added the missing POST .../{config_id}/clone route (the 1:1 rule — I hadn't consciously skipped it, which is what the rule catches), and I reverted file_size_baseline.json to main's values. Raising a grandfathered ceiling by 2 lines to fit my own addition is precisely what CONTRIBUTING.md forbids; config oauth-url moved to its own module instead, so commands/config.py shrank to 1953 code lines from 2007.

7 new tests, make check green (5644 passed). Ready for another look when you have time.

Dismissing as stale, with the PR author's authorisation. This review was submitted against f8683f0; HEAD is now a5c8bbc. All nine findings it referenced (via the Devin pass) have been fixed, each replied to on its thread and resolved — including the blocking one where a re-supplied row secret was written to the parent body instead of the row. Full summary: #596 (comment). Re-review welcome; not blocking the 0.84.2 release on it.