Fix interactive apply CLI to match push/pull flow

[vtkovapi]

Summary

• npm run apply (no org slug) now uses the same interactive flow as npm run push and npm run pull: org selection → all/pick scope → searchable resource picker → confirmation → force-mode prompt → pull → push
• Previously, interactive apply only asked for org + force mode and always ran a full-org apply, bypassing the resource picker UX

Test plan

• npm run build
• npm test
• Run npm run apply with no args and verify org picker, scope selection, resource checkbox, confirm, and force prompts appear
• Run npm run apply -- <org> and verify direct (non-interactive) apply still works
• Select a subset of resources in interactive apply and confirm only those files are passed to src/apply.ts

Made with Cursor

[dhruva-vapi]

I smoke-tested this locally against dhruva-test with disposable zz-stress-* resources. Two general things I couldn't anchor inline because the relevant lines are unchanged: (1) push/apply still prints Deletions: 🔒 Disabled (dry-run) during a real mutating run, which is confusing; (2) after a successful scoped apply, a second scoped apply of the same assistant reported both-diverged — resolving with --resolve=ours, so I think successful push/apply needs to advance or refresh the baseline used by pull drift detection, not only write lastPushedHash.

[dhruva-vapi]

Can we add an automated smoke test around this picker flow? The UX has a lot of Back/Cancel/empty-selection states, and this is exactly the kind of CLI path that can regress while unit tests for path parsing still pass.

[vtkovapi]

Probably needs to be looked closely in the a follow up?

[dhruva-vapi]

Can we make sure this scoped view is also reflected in the terminal output? In a one-file scoped apply, the command applied only the selected assistant, but the push phase still printed Loaded ... for every local resource, which makes the blast radius look larger than it is.

[vtkovapi]

Should already have been addressed

[dhruva-vapi]

Can we add a regression check that a local-wins apply does not leave the next run looking both-diverged? I hit that after applying one assistant twice: the first run succeeded, then the next run treated the prior CLI write as dashboard drift.

[vtkovapi]

Should be fixed now

[dhruva-vapi]

Thinking about the UX again, I’d adjust the product shape here rather than ask users to memorize validate && apply && avoid push. Suggested direction:

1. Make npm run apply -- <org> the one-shot safe deploy command: run validation first, then pull/reconcile, then push. Validation can stay as a separate no-network/CI/preflight command, but normal users shouldn’t have to run it manually before every apply.
2. Make raw local → dashboard push explicit/advanced: require npm run push -- <org> --direct. The current direct push behavior is useful for lower-level engine work, but it’s too easy to use as the normal deploy path. Bare push should either delegate to safe apply or print guidance telling the operator to use apply unless they intentionally pass --direct.
3. Still fix the classifier invariant so live local + dashboard agreement never reports as both-diverged. Exact code shape:

export function classifyDrift(input: ClassifyDriftInput): DriftDirection {
  const { localHash, lastPulledHash, platformHash } = input;
  if (!lastPulledHash) return "no-baseline";
  if (localHash === platformHash) return "clean";
  const localMatches = localHash === lastPulledHash;
  const platformMatches = platformHash === lastPulledHash;
  if (localMatches && platformMatches) return "clean";
  if (localMatches && !platformMatches) return "dashboard-ahead";
  if (!localMatches && platformMatches) return "local-ahead";
  return "both-diverged";
}

Regression case: localHash=B, platformHash=B, lastPulledHash=A should return clean and refresh the baseline. That can happen after apply’s push leg makes the dashboard match local while state still has the previous pull baseline.

[vtkovapi]

Apply as the one-shot safe deploy — done
push --direct — agreed in principle, logged
Classifier invariant — done

[dhruva-vapi]

did a quick local + personal-org dry-run pass here. a few things I hit that I think we should clean up before landing:

• npm test is red for me right now: 278 tests, 258 pass, 20 fail. most of the failures look clustered around drift/audit/rename/state migration.
• after pull --bootstrap, a targeted pull --type assistants --id ... treated the missing local file as deleted intent and skipped it until I added --force. I think bootstrap state-only entries probably shouldn’t make a later targeted pull look like the user intentionally deleted the file.
• cross-org copy still feels risky: I added an assistant with a hard-coded foreign UUID in model.toolIds; validate passed and push --dry-run --allow-new-files would POST it with just an Untracked tool UUID warning. I filed another linear ticket (PRISM-978) for the bigger migration/remap workflow, but I think we should at least avoid documenting raw copy as the happy path here.

[dhruva-vapi]

I think while we're touching these entrypoints, --help should short-circuit to help instead of going through the invalid-org path. I tried npm run apply -- --help (same idea for pull/push/validate) and it reads like I typed a bad org slug.

[dhruva-vapi]

I still got a lot of kinda scary output in scoped dry-run after bootstrap — 21 state-key warnings + 11 pending deletions for unrelated resources. ^ I think this is the part that makes scoped mode feel bigger than the one selected file.

[dhruva-vapi]

not a blocker ofc

[dhruva-vapi]

wanna special-case bootstrap state here? I did pull --bootstrap, then a targeted pull --type assistants --id ..., and it skipped the resource as deleted locally until I used --force, which feels surprising for a state-only setup flow.

[dhruva-vapi]

i think bootstrap in general is a confusing flow we can consider dropping this