# Changelog

## Score

- CAI 66 → 63 (-2.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 98 → 75 (-23.5)
- Architecture 69 → 69 (+0.0)
- Maturity 56 → 54 (-2.0)
- Readiness 67 → 67 (+0.0)
- Security 99 → 99 (+0.0)

## Resolved (6)

- Inconsistent execution control. CLI.start takes raw args, Client.start_workflow takes a workflow object and job names, and Workflow.start! is an instance method with no args. The CLI method does not clearly map to the Client method, and the bang (!) on Workflow.start! suggests a side-effect that isn't mirrored in the naming of Client.start_workflow.
- Inconsistent naming for deletion. CLI uses 'rm' (Unix-style), while Client uses 'destroy' (ActiveRecord-style). Furthermore, Client.destroy_workflow accepts a 'workflow' object, whereas CLI.rm accepts an 'id'. This creates confusion about whether to pass an ID or an object, and which verb to use.
- Inconsistent naming for retrieval. CLI uses 'show' (RESTful resource view), while Client uses 'find' (database lookup). Workflow also has 'find'. This implies different intents (viewing status vs retrieving object), but the signatures are similar enough to cause confusion.
- Inconsistent pagination and listing APIs. CLI.list uses simple start/stop. Client has two distinct methods: workflow_ids (returning IDs) and workflows (returning objects), both with different parameter structures (explicit by_ts/order vs kwargs). Workflow.page mirrors this but is isolated to the model. There is no single standard 'list' or 'page' interface.
- Redundant creation operations across different layers. CLI.create and Client.create_workflow appear to be thin wrappers or duplicates of the core Workflow.create logic, but with inconsistent argument signatures (name vs args/kwargs). This forces users to choose between a CLI-specific method, a Client-specific method, or the Model method without a clear hierarchy.
- Workflow token permissions not restricted

## New (10)

- CLI offers a combined 'create_and_start' operation, while the Client API requires two separate calls (create_workflow then start_workflow). This inconsistency forces CLI users to have a simpler workflow than programmatic users.
- Four different methods for listing/retrieving workflows with inconsistent parameter names and return types. CLI.list returns display data, Client.workflow_ids returns IDs, Client.workflows returns objects, and Workflow.page is a class method. The parameter 'start/stop' vs 'order' vs 'kwargs' is inconsistent.
- Orphaned file (lib/gush/cli.rb)
- Orphaned file (lib/gush/cli/overview.rb)
- Orphaned file (lib/gush/client.rb)
- Orphaned file (lib/gush/job.rb)
- Orphaned file (lib/gush/workflow.rb)
- Three distinct entry points for creating a workflow exist with different signatures and responsibilities. CLI.create is a high-level CLI command, Client.create_workflow is a client-side API call, and Workflow.create is a model-level factory. This forces users to choose the correct layer without a clear unified entry point.
- Three methods for retrieving a workflow by ID. CLI.show is for display, Client.find_workflow is for client retrieval, and Workflow.find is a model lookup. This duplication creates confusion about which method to use for programmatic access.
- Workflow token permissions not restricted (.github/workflows/ruby.yml)