There There Cli Laravel Package

Product Decisions This Supports

Build vs. buy — and the framing question first. This is not a library we require into the application. It is a standalone Laravel Zero CLI, installed via composer global require, that shells out to one command per There There API endpoint. So it does not answer "how do we integrate the helpdesk into our product" — it answers "how do we automate our operations around the helpdesk without building a service." Treat those as two separate roadmap lines. This package unlocks the second one this quarter at roughly zero engineering cost; the first still needs an HTTP client, retries, typed DTOs, and queued workers that we own.

Roadmap items it makes cheap:

• Support reporting digest — scheduled job calls list-tickets --filter-status=open / --filter-created-after=..., parses JSON, posts a summary. No new service, no new deploy target.
• SLA sweep and escalation routing — a console command detects ageing tickets and calls update-ticket-assignee / update-ticket-team to route them. This is the highest-value, lowest-effort win.
• Bulk remediation — one-off scripts for tag cleanup (add-tag-to-ticket / remove-tag-from-ticket), status correction, or migrating tickets between teams. Replaces an afternoon of clicking.
• Multi-brand / multi-workspace support — named profiles plus per-request --profile and an X-Workspace-Id header mean multi-tenant support ops is a supported shape, not bespoke token juggling. If multi-brand is on the roadmap, this de-risks the ops side of it for free.
• Metrics groundwork — list-ticket-activities plus JSON output lets us compute time-to-first-response and reopen rates before we commit to a warehouse project.

Features it lets us defer or descope: an internal admin UI for ticket triage, a custom Slack bot for support ops, and any "support ops microservice." If the CLI covers the workflow for two quarters, we don't build those.

Organisational use cases beyond automation: onboarding new support engineers (one install, --help on every command), staging/QA data setup, CI smoke tests against the helpdesk API, and AI-assisted triage — the repo ships an agent skill (there-there install-skill) that teaches coding agents the command surface, which is genuinely relevant if we want on-call engineers driving triage from a terminal rather than a browser.

Decision this informs: whether to invest a quarter in a real integration. Run the CLI version first, measure whether the workflows stick, then decide. That's a cheap option on an expensive commitment.

When to Consider This Package

Adopt when most of these are true:

• The need is operational — scheduled, batch, or interactive — not in the request path of a customer-facing feature.
• The team is already PHP/Laravel, so a Composer-global binary is a familiar dependency rather than a foreign runtime.
• You need multi-workspace access; profiles are the strongest reason to pick this over hand-rolled curl scripts.
• Volume is human-scale or low-frequency batch. Every invocation is a fresh process with no connection reuse — fine for a 15-minute digest, wrong for anything per-request.
• You can tolerate pre-1.0 churn and will pin the version, wrapping it in our own thin command layer so upstream renames don't break schedulers.
• You accept the release discipline: the PHAR is committed to the repo and must be rebuilt before tagging — 0.8.0 shipped a stale binary and 0.8.1 existed solely to fix it. Pin, then verify there-there --version after every bump.

Look elsewhere when:

• You need runtime integration inside the app — retries, idempotency, typed responses, queue workers, backoff. That's ours to build; the CLI gives you none of it.
• Auth must be organisational, not personal. Credentials live in ~/.there-there/config.json (0600) scoped to an individual's API token — that's a bus-factor and offboarding problem, and a blocker under stricter access-control review.
• You need webhook-driven or event-triggered flows; this is pull-only request/response.
• You're not on PHP, or you need the integration to be a library you can test in-process.
• You need community-vetted maturity. Zero stars, zero dependents — this is effectively unproven in the wild. Vendor pedigree (Spatie) is real, but it is not the same as a battle-tested dependency. For a mutation-capable tool touching customer support tickets, that gap belongs in the risk register, not the fine print.

One hazard worth naming explicitly: profiles are convenience and blast radius. A scheduled mutation job that silently falls back to the wrong profile can close or reassign real customer tickets in the wrong workspace. Any adoption must mandate explicit --profile on every mutation and a dry-run mode in our wrapper.

How to Pitch It (Stakeholders)

To executives — one paragraph: There's a small, free, vendor-maintained command-line tool for our helpdesk that lets us automate support busywork — daily digests, SLA escalation, bulk cleanup — without standing up a new service, hiring, or committing a quarter of engineering. It's reversible: a single laptop install and one scheduled job. The risks are narrow and known — it's pre-1.0 so command names may shift, credentials are personal API tokens in a local file, and it's a single-vendor dependency with no community track record yet. The ask is one engineer for one to two days to prove whether the toil savings are real. If they aren't, we've spent two days; if they are, we've avoided building an admin tool.

To engineering — the shape: treat there-there as an external binary, not a library. Invoke it through Symfony\Component\Process\Process, consume JSON from stdout, treat non-zero exit as failure, and pin the global version in our provisioning. Wrap every command we depend on in our own thin class so an upstream rename is a one-line fix instead of a broken cron. Never issue a mutation without an explicit --profile, and build a dry-run flag into the wrapper before the first scheduled write. Do not use it in the request path.

The decision requested: approve a timeboxed spike — not adoption. Success criteria up front: one scheduled job running unattended for two weeks, a measured reduction in manual triage minutes, and no wrong-workspace mutations. Meet those and we revisit a deeper integration with real data; miss them and we've bought a cheap, well-documented "no."