@learnaltitude/cli 0.2.0 → 0.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +85 -4
  2. package/dist/cli.js +50 -44
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -12,6 +12,75 @@ npm install -g @learnaltitude/cli
12
12
  Pair the CLI with your account at [app.learnaltitude.com](https://app.learnaltitude.com).
13
13
  Supported agents are Claude Code and Codex.
14
14
 
15
+ ## Connect, bind, and inspect a project
16
+
17
+ From a terminal, name the agent this computer will use and complete the browser device flow:
18
+
19
+ ```sh
20
+ altitude connect --agent claude-code
21
+ altitude connect --agent codex
22
+ ```
23
+
24
+ Use one command, not both. Codex requires Codex CLI 0.131.0 or newer; its adapter-native connect
25
+ command enforces that floor, while the raw terminal command does not. Connecting stores a scoped
26
+ bearer token in the CLI data directory (by default, `~/.altitude/token.json`) with owner-only
27
+ permissions; it does not activate hooks in every directory.
28
+
29
+ A directory declares WHICH journey it works. From the root of the project, pick from your
30
+ journey list:
31
+
32
+ ```sh
33
+ altitude bind --list # show your journeys and their statuses
34
+ altitude bind --journey <id> # bind this directory to one of them
35
+ altitude bind # binds directly when exactly one journey is bindable
36
+ ```
37
+
38
+ Binding writes a `.altitude` marker in that directory. Hooks discover the nearest marker while
39
+ walking upward, so the project and its subdirectories are active; invocations without a working
40
+ directory or valid marker are dormant and produce no capture, down-sync, context, or gate work.
41
+ Binding during a running agent session takes effect on its next learner turn or tool lifecycle;
42
+ you do not need to restart the agent.
43
+ Gate failures in a bound project still fail open. Several directories may bind the same journey
44
+ (git worktrees are the normal case); each directory holds exactly one journey, and its down-synced
45
+ working set is cached per journey in an owner-only file for offline sessions. An abandoned journey
46
+ stays visible in the list but cannot be bound; a paused journey can. When the refreshed or cached
47
+ journey list marks it paused, session start prints the server's paused notice when present and
48
+ keeps gates dormant until a later list refresh observes that you resumed it on Altitude (never
49
+ automatically from the terminal). Older responses without a notice stay silent. When the server
50
+ refuses a binding's journey (deleted, abandoned, or not entitled), the session prints the server's
51
+ explanation instead of silently substituting another project.
52
+ `altitude diagnostics` records these misses and stale bindings; the precise hook behavior is
53
+ defined in the [workshop/server
54
+ protocol](../../docs/mvp-plan.md#workshop--server-protocol-packagesshared).
55
+ If the project is already bound to another journey, inspect the IDs before deliberately replacing
56
+ the marker with `altitude bind --force`.
57
+
58
+ Use `altitude task --json` for a network-first snapshot of the BOUND journey with local-cache
59
+ fallback; its `source` field says which was used, `journey_status` carries the journey's
60
+ last-known status, and `journey_miss` carries the server's refusal when the bound journey was not
61
+ served. Its full shape is the
62
+ [`taskEnvelopeSchema`](../shared/src/workshop.ts) contract. `altitude status` is a local snapshot
63
+ that includes the nearest binding plus the bound journey's cached working-set summaries. Binding
64
+ requires a connected device token; the command tells unconnected users to connect and directs
65
+ users without a bindable journey back to Altitude.
66
+
67
+ The envelope also carries `update_available`, a client-local boolean: true when a **copied** skills
68
+ install (or the CLI itself) is behind what the last background version check saw upstream. It is
69
+ read from the local update-check cache only — `altitude task` never makes a version request, so a
70
+ lesson never waits on one — and it is always false for marketplace/plugin-managed skills, which
71
+ update with the agent rather than through `altitude update`.
72
+
73
+ Tutor flows can attach a graded answer to its canonical concepts so the server can update the
74
+ corresponding mastery cards:
75
+
76
+ ```sh
77
+ altitude emit quiz-moment --session <id> --question <q> --answer <a> \
78
+ --verdict <correct|partial|incorrect> --concepts <id,...>
79
+ ```
80
+
81
+ `--concepts` accepts comma-separated IDs or repeated flags. The CLI trims empty entries, removes
82
+ duplicates in first-seen order, and omits `concept_ids` when no non-empty ID is supplied.
83
+
15
84
  ## Copied skills installs and updates
16
85
 
17
86
  Claude Code marketplace installs remain the recommended Claude path and update through that
@@ -46,7 +115,19 @@ command instead. A genuine copied-skills sync failure stops before the CLI self-
46
115
  The distributed client uses the user's own agent subscription and no Altitude-held API key.
47
116
  Interactive `connect`, `diagnostics`, and `update` commands make anonymous, direct version checks
48
117
  to GitHub (the public skills repository's `main` commit) and the npm registry (the CLI's latest
49
- version). Results are cached in the CLI data directory for about 24 hours. Skills downloads also
50
- come directly from GitHub. These requests do not pass through the Altitude service and carry no
51
- Altitude credentials. Hooks, gates, queue flushers, and other non-interactive paths never perform
52
- the version check; all check failures are silent and cannot change a command's exit code.
118
+ version). Check attempts are throttled for about 24 hours; the latest usable result remains cached
119
+ until a later successful check replaces it. Skills downloads also come directly from GitHub. These
120
+ requests do not pass through the Altitude service and carry no Altitude credentials.
121
+
122
+ A bound SessionStart schedules the same anonymous check without awaiting it, and the detached
123
+ flusher daemon keeps doing so in the background. Background checks run only on a device that holds
124
+ a copied skills install — otherwise the answer could never change anything the CLI can act on. The
125
+ SessionStart process exits roughly 250 ms after its command completes, so this scheduling improves
126
+ spawn-fallback coverage only when both version requests settle inside that remaining budget; it
127
+ does not guarantee fallback coverage. An interrupted attempt writes no marker and therefore cannot
128
+ suppress a later daemon or command attempt. Because unbound directories keep hooks dormant, they
129
+ do not start a flusher or receive background refreshes; their cache is refreshed only by
130
+ `connect`, `diagnostics`, or `update`. `altitude task --json` only reads the cache and never makes a
131
+ request itself. Gates and other hooks never perform the version check. Set
132
+ `ALTITUDE_DISABLE_UPDATE_CHECK=1` to turn every version check off. All check failures are silent
133
+ and cannot change a command's exit code or discard a previously usable cache result.