[HAR] harness execute registry:migrate — parity gaps and bugs vs hc

[sameeksha-harness]

Summary

Comparison of harness execute registry:migrate against the hc CLI revealed the following bugs and missing features:

Bugs

1. Failed artifacts don't fail the run
If one or more artifacts fail to migrate, the command still exits 0 and prints "Migration completed successfully." Automation and CI pipelines will treat a partial migration as a success.

2. packageFilters silently dropped
hc supports a packageFilters config field to migrate only specific packages, this command uses includePatterns/excludePatterns instead. So a customer who pastes their working hc config expecting a filtered migration will silently get the entire registry migrated instead as YAML parsers silently ignore that field.

3. Unknown artifactType not rejected at config load
hc rejects unknown/mistyped artifact types immediately at config load before making any network calls. harness silently accepts them, contacts both source and destination registries, then fails mid-run with "get packages failed: unknown artifact type" — still printing "Migration completed successfully." and exiting 0.
Verified: artifactType: generic (lowercase)

• harness — hits both registries, fails mid-run, empty stats table, exits 0
• hc — fails at load: unknown artifactType "generic" — valid values are: DOCKER, HELM, ..., exits 1

Missing features

4. Missing artifact types — CRAN, RUBY, TERRAFORM are supported by hc but not by this command. These are not just missing from the type list — the CLI accepts them silently, makes live network calls to both registries, then fails mid-run with "unknown artifact type", exits 0, and prints "Migration completed successfully." with nothing migrated.

5. --result-file — hc writes one JSON-lines record per artifact so automation can inspect exact outcomes even on failure. No equivalent here.

6. --summary flag — to suppress/control the final stats table output.

7. Missing artifact types — CRAN, RUBY, TERRAFORM are supported by hc but not by this command.

8. No skip reason — when an artifact is skipped, there's no indication of why (already exists, nothing to migrate, etc.).

9. Config file not documented in help — hc ships example configs. New users have no idea what the config file should look like.

Note: Bugs 3 and 4 share the same root cause — validateConfig in modules/har/pkg/har/migrate/types/config.go has no IsKnownArtifactType() check