Repository navigation
Feature/api client mode - #3
Merged
Merged
Conversation
Tier 2. CSAX_API_URL/CSAX_API_EMAIL/CSAX_API_PASSWORD, a minimal net/http-based client (login, transparent refresh, one retry on a 401), a local session cache (~/.csax/session.json, mode 0600, never the password), and csax login/logout to prove the round trip. DATABASE_URL is now only required in direct-DB mode — requiring it unconditionally would have defeated the entire point of API-client mode, so loadConfig's check is now gated on APIURL being unset. csax migrate gets its own explicit DATABASE_URL check instead, since it always stays direct-DB regardless of mode. 403 not_operator and 501 not_implemented_on_sqlite get plain-English hints rather than a bare status dump. Verification: apiclient.go/cmd_login.go have zero cryden imports and were confirmed resolving clean against golang.org/x/term's real API in isolation (mirrored through github.com/golang/term since golang.org itself isn't reachable here). The full package still hits the same go-webauthn/Go 1.25 floor api's own Tier 0 hit — confirmed that's the *only* remaining blocker, not anything in this new code. Not independently built end to end for that reason.
Tier 3. Same JSON output shape in both modes — a script parsing --json output shouldn't need to know which mode produced it. users get costs two round trips in API-client mode (search, then detail) where direct-DB mode needed one query; that's the accepted cost of not holding a database credential. users create/unlock stay direct-DB only, unconditionally — api has no matching endpoint for either, on purpose, see CLAUDE.md.
Tier 4. Honestly not output-identical to direct-DB mode, unlike users list/get: api's oauth health endpoint reports one configured bool per provider rather than separately which of client ID/secret is missing, but in exchange does a real live reachability probe for every provider in one call, something direct-DB mode's list never did at all. Documented as a real difference, not papered over. Noted, not fixed here (out of this tier's scope): oauthProviders() in cmd_oauth.go still only lists google/github — api itself has supported microsoft/discord/gitlab/apple since its own Tier 1, so direct-DB mode's provider list is now stale independent of anything in this PR.
Tier 5. Calls the target deployment's public GET /v1/health directly — deliberately bypasses client.get/login entirely, since a health check should work with no operator credential at all, the same way direct-DB mode's health check needs no admin access either. Also fixes targetCrydenVersion, left stale at v2.1.0 by this branch's own Tier 0 commit — should have been caught there.
Tier 6. Brand new surface, both modes work: cryden.WeeklyDigest/
DigestSince, DiagnoseLoginIssue, and ConfigTuningReport/
TuningReportSince are plain engine functions taking only the
*cryden.Engine direct-DB mode already builds elsewhere, so there's
no reason to make these API-client-only.
csax config-tuning renders api's structured {area,finding,suggestion}
list the same way the direct-DB text report reads, so the two modes
don't look like different tools.
digest history has no direct-DB equivalent at all and says so
plainly rather than silently doing nothing — cryden's own
WeeklyDigest only ever answers on demand, there's no local concept
of scheduled digest history to read.
Signature note: this sandbox's local reference copy of cryden turned
out to be a stale, pre-Tier-4 snapshot (no admin/ai/widget packages
at all), so these three engine calls were written from the exact
signatures verified earlier in this same project, not re-checked
against that copy.
Tier 7, final tier from NEXT.md. API-client mode only, permanently — the reviewed_anomalies table this reads is api's own addition to its own Postgres schema, not part of cryden's, so there is no direct-DB path for this command at all, ever. Says so plainly if CSAX_API_URL isn't set rather than trying to fake a local equivalent. Confirming takes no action on the account itself — no lock, no revoke — matching the same read-only-in-spirit reasoning api's own admin.mdx documents for this same feature.
Added instructions for setting up PATH for csax installation on Linux, macOS, and Windows.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.