Skip to content

planned6.md

Latest commit

 

History

History
74 lines (48 loc) · 2.94 KB

planned6.md

File metadata and controls

74 lines (48 loc) · 2.94 KB

CLI Project Integration Strategy

TaskHelm CLI should become the workflow layer that turns TaskHelm Engine from an internal service into a tool developers can actually live with inside repositories. That means the CLI has to understand where it is running, what project it belongs to, and which local defaults should shape routing and output behavior before a user starts repeating long flags.

Integration Model

The CLI should treat a repository or workspace as the primary unit of integration.

  • discover a workspace root from taskhelm.config.json or YAML first
  • fall back to common workspace markers such as .git, package.json, or pnpm-workspace.yaml
  • allow a user-level config to define broad defaults across machines
  • allow a project config to specialize engine endpoint, preferred policies, stage overrides, and output defaults for one codebase

This layering gives platform teams a stable place to encode project routing defaults without forcing every developer to maintain identical user config.

Recommended Config Precedence

  1. built-in CLI defaults
  2. user CLI config
  3. local project config
  4. environment overrides
  5. explicit command-line flags

That ordering keeps project-specific behavior visible and versioned, while still giving operators and CI jobs a clean override path.

Repository-Level Use Cases

Local Development

Developers should be able to run TaskHelm from the root of a repo and inherit:

  • the correct engine endpoint
  • preferred routing policies for that project
  • stage-specific model overrides
  • shell-friendly or pretty output defaults depending on the team

Team Standards

Project config should become the place where a team encodes conventions such as:

  • documentation tasks favor low-cost modes
  • implementation stages prefer stronger coding profiles
  • review or testing stages prefer faster feedback loops

Internal Tooling

Wrapper scripts, editor integrations, and repo-local automation should call the CLI rather than speak raw engine HTTP where practical. The CLI can stabilize request construction, exit semantics, and config discovery for those tools.

Rollout Strategy

Phase 1

  • support user config and local project config
  • expose taskhelm init
  • make task create, route-preview, and watch repo-aware

Phase 2

  • add richer project-level policy editing helpers
  • add validation commands for project config
  • add shell completions and template generators

Phase 3

  • integrate with editor plugins and preconfigured repo tasks
  • add richer login/profile resolution once auth exists
  • support remote project metadata and cloud policy sync without removing local override control

Guardrails

  • project config should remain explicit, reviewable, and small
  • user config should not silently absorb project-local settings
  • CLI behavior should surface where a value came from whenever that is relevant to debugging
  • workspace-aware defaults should never prevent explicit command-line overrides