codeam-cli 2.61.26 → 2.61.27
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.
- package/CHANGELOG.md +6 -0
- package/dist/index.js +153 -30
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,12 @@ All notable changes to `codeam-cli` are documented here.
|
|
|
4
4
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
6
6
|
|
|
7
|
+
## [2.61.26] — 2026-07-23
|
|
8
|
+
|
|
9
|
+
### Fixed
|
|
10
|
+
|
|
11
|
+
- **cli:** Classify 'OAuth session expired … could not be refreshed' as an auth failure
|
|
12
|
+
|
|
7
13
|
## [2.61.25] — 2026-07-23
|
|
8
14
|
|
|
9
15
|
### Fixed
|
package/dist/index.js
CHANGED
|
@@ -806,7 +806,7 @@ function isKnownIntegrationId(id) {
|
|
|
806
806
|
return id in INTEGRATION_REGISTRY;
|
|
807
807
|
}
|
|
808
808
|
|
|
809
|
-
// ../../packages/shared/src/skills/
|
|
809
|
+
// ../../packages/shared/src/skills/code-review.ts
|
|
810
810
|
var CODE_REVIEW_BODY = `Use this skill when reviewing a pull request. It defines what a high-signal
|
|
811
811
|
review looks like so your inline comments are worth the author's time.
|
|
812
812
|
|
|
@@ -839,6 +839,18 @@ line, each led by a severity tag (blocker/should-fix/nit) and a concrete reason
|
|
|
839
839
|
(the failure scenario or risk), not a restatement of the diff. If the change is
|
|
840
840
|
correct and well-tested, approve and say so \u2014 finding nothing is a valid outcome.
|
|
841
841
|
Review only the diff and its direct blast radius; do not demand unrelated refactors.`;
|
|
842
|
+
var codeReviewSkill = {
|
|
843
|
+
id: "code-review",
|
|
844
|
+
name: "Code Review",
|
|
845
|
+
description: `High-signal PR review: prioritize correctness \u2192 security \u2192 tests \u2192 clarity, one anchored finding per comment.`,
|
|
846
|
+
source: "curated",
|
|
847
|
+
delivery: {
|
|
848
|
+
skillFile: { body: CODE_REVIEW_BODY },
|
|
849
|
+
instruction: { body: CODE_REVIEW_INSTRUCTION }
|
|
850
|
+
}
|
|
851
|
+
};
|
|
852
|
+
|
|
853
|
+
// ../../packages/shared/src/skills/resolve-conflicts.ts
|
|
842
854
|
var RESOLVE_CONFLICTS_BODY = `Use this skill when resolving merge conflicts on a pull request. The goal is a
|
|
843
855
|
merge that preserves BOTH sides' intent, not one that just makes the file compile.
|
|
844
856
|
|
|
@@ -862,28 +874,134 @@ and prefer a union of intents; drop a side only when the two are mutually exclus
|
|
|
862
874
|
keeping the side that matches the PR's purpose. Leave no conflict markers behind
|
|
863
875
|
(grep for them). Regenerate lockfiles rather than hand-merging them. The result must
|
|
864
876
|
build and pass tests \u2014 run them \u2014 before you commit and push.`;
|
|
865
|
-
var
|
|
866
|
-
"
|
|
867
|
-
|
|
868
|
-
|
|
869
|
-
|
|
870
|
-
|
|
871
|
-
|
|
872
|
-
|
|
873
|
-
|
|
874
|
-
|
|
875
|
-
|
|
876
|
-
|
|
877
|
-
|
|
878
|
-
|
|
879
|
-
|
|
880
|
-
|
|
881
|
-
|
|
882
|
-
|
|
883
|
-
|
|
884
|
-
|
|
877
|
+
var resolveConflictsSkill = {
|
|
878
|
+
id: "resolve-conflicts",
|
|
879
|
+
name: "Resolve Conflicts",
|
|
880
|
+
description: `Merge-conflict resolution that preserves both sides' intent, leaves no markers, and keeps the build green.`,
|
|
881
|
+
source: "curated",
|
|
882
|
+
delivery: {
|
|
883
|
+
skillFile: { body: RESOLVE_CONFLICTS_BODY },
|
|
884
|
+
instruction: { body: RESOLVE_CONFLICTS_INSTRUCTION }
|
|
885
|
+
}
|
|
886
|
+
};
|
|
887
|
+
|
|
888
|
+
// ../../packages/shared/src/skills/spec-driven-development.ts
|
|
889
|
+
var SPEC_DRIVEN_BODY = `Use this skill for any coding task that isn't a trivial one-liner. Build the right
|
|
890
|
+
thing, provably, with the least ceremony the task warrants \u2014 specification before
|
|
891
|
+
code, but its depth scales to the work. Skipping it yields code that looks right yet
|
|
892
|
+
solves the wrong problem or breaks something you never checked.
|
|
893
|
+
|
|
894
|
+
## Step 0 \u2014 Right-size the work (always first)
|
|
895
|
+
- **Quick** \u2014 a typo, copy tweak, one-line fix, a single file with no unknowns.
|
|
896
|
+
No ceremony: make the change, run the relevant test/build, confirm it. Do NOT
|
|
897
|
+
write a spec for a typo.
|
|
898
|
+
- **Standard** \u2014 a feature or fix across a few files, some unknowns, a testable
|
|
899
|
+
outcome. A light inline pass (a 2-3 sentence spec + a short plan), then build
|
|
900
|
+
test-first, then verify. No scaffolding files.
|
|
901
|
+
- **Deep** \u2014 large, ambiguous, risky, or touching many files / shared contracts /
|
|
902
|
+
data / auth. The full flow below, tracking the work in beads (\`bd\`), not scratch
|
|
903
|
+
files.
|
|
904
|
+
When unsure, start one level lighter and escalate the moment real ambiguity or risk
|
|
905
|
+
appears. State which level you picked in one line.
|
|
906
|
+
|
|
907
|
+
## Step 1 \u2014 Ground in the real codebase (before specifying anything non-trivial)
|
|
908
|
+
You are almost never in a greenfield. Before you spec or plan, survey the real code:
|
|
909
|
+
the existing patterns for this kind of change, the files you'll touch, the test
|
|
910
|
+
setup, prior art, and the constraints (auth, data, shared types, CLAUDE.md
|
|
911
|
+
conventions). A spec written in a vacuum produces a plan that fights the codebase.
|
|
912
|
+
Read first; never assume.
|
|
913
|
+
|
|
914
|
+
## Step 2 \u2014 Specify: the WHAT and WHY (not the HOW)
|
|
915
|
+
State the user-visible outcome and why it matters, then the acceptance criteria \u2014
|
|
916
|
+
each concrete and testable ("tapping X shows Y", "the endpoint returns 409 when Z"),
|
|
917
|
+
never vague ("works well"). List what is out of scope. Put NO implementation detail
|
|
918
|
+
here (no file names, no libraries). If a requirement is ambiguous, mark it rather
|
|
919
|
+
than guess.
|
|
920
|
+
|
|
921
|
+
## Step 3 \u2014 Clarify: resolve ambiguity, but don't stall
|
|
922
|
+
Gather the ambiguities that would actually change what you build. Ask the
|
|
923
|
+
highest-leverage ones \u2014 batched, at most ~3, phrased as concrete choices. For
|
|
924
|
+
low-stakes unknowns, pick a sensible default and SAY so ("assuming X unless you tell
|
|
925
|
+
me otherwise") instead of asking. On a conversational/mobile client every round-trip
|
|
926
|
+
is expensive \u2014 don't pester; decide what you safely can.
|
|
927
|
+
|
|
928
|
+
## Step 4 \u2014 Plan: the HOW, grounded and simple
|
|
929
|
+
Design against the real code. Apply the simplicity gates before committing:
|
|
930
|
+
- **Fewest moving parts** that satisfy the criteria. If you add a layer or
|
|
931
|
+
abstraction, justify it or drop it.
|
|
932
|
+
- **Use the framework/library directly** \u2014 don't wrap it for flexibility you don't
|
|
933
|
+
need yet.
|
|
934
|
+
- **Minimal blast radius** \u2014 touch what the change needs, nothing more.
|
|
935
|
+
State the test strategy (what proves each criterion) and name the real risks. Keep
|
|
936
|
+
the plan short.
|
|
937
|
+
|
|
938
|
+
## Step 5 \u2014 Tasks: small, verifiable, ordered
|
|
939
|
+
Split the plan into tasks that each end in something you can run and check. Mark
|
|
940
|
+
independent ones as parallelizable. Each task is the smallest unit worth its own
|
|
941
|
+
check. Sequence by dependency.
|
|
942
|
+
|
|
943
|
+
## Step 6 \u2014 Implement: test-first by default
|
|
944
|
+
For each task: write the test that would fail without the change, watch it fail, make
|
|
945
|
+
it pass, keep it green. Follow the patterns you found in Step 1. Commit in logical
|
|
946
|
+
units. Escape hatch: for a genuine spike or exploratory UI where test-first is
|
|
947
|
+
impractical, say so explicitly and add the test right after \u2014 never skip it silently.
|
|
948
|
+
|
|
949
|
+
## Step 7 \u2014 Verify + self-review (what separates "done" from "looks done")
|
|
950
|
+
Return to the acceptance criteria and prove EACH one is met \u2014 run the tests, diff the
|
|
951
|
+
behavior, look at the real output. Then review your own work adversarially:
|
|
952
|
+
- What did I NOT test?
|
|
953
|
+
- What did I change that I didn't need to?
|
|
954
|
+
- What could this have broken (the blast radius)?
|
|
955
|
+
- Does anything contradict the spec?
|
|
956
|
+
Fix what you find before declaring done. "The tests I wrote pass" is not "it works".
|
|
957
|
+
|
|
958
|
+
## Step 8 \u2014 Done + handoff
|
|
959
|
+
Done means acceptance criteria met, tests green, no known regressions. Summarize what
|
|
960
|
+
changed in plain terms. File any deferred work or follow-ups to beads (\`bd\`) so
|
|
961
|
+
nothing is lost. Never claim done on unverified work.
|
|
962
|
+
|
|
963
|
+
## Principles (the constitution)
|
|
964
|
+
- Clarify before you build; verify before you call it done.
|
|
965
|
+
- Testable beats descriptive \u2014 a criterion you can't check isn't one.
|
|
966
|
+
- Grounded beats greenfield \u2014 fit the codebase that exists.
|
|
967
|
+
- Simple beats clever \u2014 the least structure that works.
|
|
968
|
+
- Scale the process to the task \u2014 ceremony on a typo is a bug.
|
|
969
|
+
- Real work goes to beads, not throwaway files in someone's repo.`;
|
|
970
|
+
var SPEC_DRIVEN_INSTRUCTION = `Follow spec-driven development, scaled to the task:
|
|
971
|
+
1. Right-size first. A trivial change (typo, one file, no unknowns) \u2192 just make it
|
|
972
|
+
well and verify, no ceremony. A feature/ambiguous/risky change \u2192 spec \u2192 plan \u2192
|
|
973
|
+
build \u2192 verify.
|
|
974
|
+
2. Ground in the real codebase before planning \u2014 read the existing patterns, tests,
|
|
975
|
+
and constraints. Never assume; read first.
|
|
976
|
+
3. Specify the WHAT and WHY as testable acceptance criteria, not the HOW. Mark
|
|
977
|
+
ambiguities instead of guessing.
|
|
978
|
+
4. Clarify only the highest-leverage unknowns (batch <=3, concrete choices); default
|
|
979
|
+
the low-stakes ones and say so. Don't stall on round-trips.
|
|
980
|
+
5. Plan the simplest approach that fits the code: fewest moving parts, use libraries
|
|
981
|
+
directly, minimal blast radius. State how each criterion will be tested.
|
|
982
|
+
6. Implement test-first by default; follow existing patterns; commit in logical units.
|
|
983
|
+
7. Verify EACH acceptance criterion (run tests, diff behavior), then self-review
|
|
984
|
+
adversarially: what's untested? what did I change needlessly? what could I have
|
|
985
|
+
broken? what contradicts the spec? Fix before declaring done.
|
|
986
|
+
8. Track deferred work in beads (bd), not scratch files. Simple beats clever; verify
|
|
987
|
+
before done.`;
|
|
988
|
+
var specDrivenDevelopmentSkill = {
|
|
989
|
+
id: "spec-driven-development",
|
|
990
|
+
name: "Spec-Driven Development",
|
|
991
|
+
description: `Spec-driven development scaled to the task: right-size, ground in the code, write testable acceptance criteria, plan simply, build test-first, and verify every criterion before done.`,
|
|
992
|
+
source: "curated",
|
|
993
|
+
delivery: {
|
|
994
|
+
skillFile: { body: SPEC_DRIVEN_BODY },
|
|
995
|
+
instruction: { body: SPEC_DRIVEN_INSTRUCTION }
|
|
885
996
|
}
|
|
886
997
|
};
|
|
998
|
+
|
|
999
|
+
// ../../packages/shared/src/skills/registry.ts
|
|
1000
|
+
var SKILL_REGISTRY = {
|
|
1001
|
+
"code-review": codeReviewSkill,
|
|
1002
|
+
"resolve-conflicts": resolveConflictsSkill,
|
|
1003
|
+
"spec-driven-development": specDrivenDevelopmentSkill
|
|
1004
|
+
};
|
|
887
1005
|
function isSkillId(id) {
|
|
888
1006
|
return Object.prototype.hasOwnProperty.call(SKILL_REGISTRY, id);
|
|
889
1007
|
}
|
|
@@ -1024,7 +1142,12 @@ var USER_EVENTS = {
|
|
|
1024
1142
|
// VCS / PR Command Center — the backend publishes this after an agent finishes
|
|
1025
1143
|
// reviewing a PR (verdict + comment count + findings), driving the mobile
|
|
1026
1144
|
// completion screen + push. Mirrored in repo A's app-shared events.ts.
|
|
1027
|
-
VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete"
|
|
1145
|
+
VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete",
|
|
1146
|
+
/** PR-review launch progress toast — the "Review with an agent" flow shows a
|
|
1147
|
+
* toast when the review runs server-side (Inngest). Mobile-only surface,
|
|
1148
|
+
* produced by api-v2 (the CLI neither produces nor consumes it). Mirrored in
|
|
1149
|
+
* repo A. */
|
|
1150
|
+
PR_REVIEW_LAUNCH: "pr_review_launch"
|
|
1028
1151
|
};
|
|
1029
1152
|
|
|
1030
1153
|
// ../../packages/shared/src/preview-prompts.ts
|
|
@@ -6117,7 +6240,7 @@ function readAnonId() {
|
|
|
6117
6240
|
}
|
|
6118
6241
|
function superProperties() {
|
|
6119
6242
|
return {
|
|
6120
|
-
cliVersion: true ? "2.61.
|
|
6243
|
+
cliVersion: true ? "2.61.27" : "0.0.0-dev",
|
|
6121
6244
|
nodeVersion: process.version,
|
|
6122
6245
|
platform: process.platform,
|
|
6123
6246
|
arch: process.arch,
|
|
@@ -6298,7 +6421,7 @@ var os4 = __toESM(require("os"));
|
|
|
6298
6421
|
// package.json
|
|
6299
6422
|
var package_default = {
|
|
6300
6423
|
name: "codeam-cli",
|
|
6301
|
-
version: "2.61.
|
|
6424
|
+
version: "2.61.27",
|
|
6302
6425
|
description: "Workflow-continuity bridge for AI coding agents. Wrap Claude Code or Codex in a PTY and supervise, approve, and redirect the session from any device \u2014 async. The terminal companion for CodeAgent Mobile.",
|
|
6303
6426
|
type: "commonjs",
|
|
6304
6427
|
main: "dist/index.js",
|
|
@@ -7469,7 +7592,7 @@ var CommandRelayService = class _CommandRelayService {
|
|
|
7469
7592
|
// fresh + clear the "CLI update available" banner after a self-update
|
|
7470
7593
|
// (a codespace that reinstalls @latest reconnects via heartbeat, not
|
|
7471
7594
|
// pair/reconnect). Older backends ignore the extra field.
|
|
7472
|
-
..."2.61.
|
|
7595
|
+
..."2.61.27" ? { ideVersion: "2.61.27" } : {}
|
|
7473
7596
|
}).then(() => log.trace("relay", `heartbeat ok online=${online}`)).catch((err) => log.trace("relay", `heartbeat failed online=${online}`, err));
|
|
7474
7597
|
}
|
|
7475
7598
|
/**
|
|
@@ -18331,7 +18454,7 @@ async function autoUpgradeBeforeCriticalCommand() {
|
|
|
18331
18454
|
if (process.env.NODE_ENV === "test") return;
|
|
18332
18455
|
if (process.env.CODEAM_DISABLE_UPDATE_CHECK === "1") return;
|
|
18333
18456
|
if (process.env.CI) return;
|
|
18334
|
-
const current = true ? "2.61.
|
|
18457
|
+
const current = true ? "2.61.27" : null;
|
|
18335
18458
|
if (!current) return;
|
|
18336
18459
|
const cache = readCache();
|
|
18337
18460
|
const fresh = cache && Date.now() - cache.fetchedAt < TTL_MS;
|
|
@@ -18348,7 +18471,7 @@ function checkForUpdates() {
|
|
|
18348
18471
|
if (process.env.CODEAM_DISABLE_UPDATE_CHECK === "1") return;
|
|
18349
18472
|
if (process.env.CI) return;
|
|
18350
18473
|
if (!process.stdout.isTTY) return;
|
|
18351
|
-
const current = true ? "2.61.
|
|
18474
|
+
const current = true ? "2.61.27" : null;
|
|
18352
18475
|
if (!current) return;
|
|
18353
18476
|
const cache = readCache();
|
|
18354
18477
|
const fresh = cache && Date.now() - cache.fetchedAt < TTL_MS;
|
|
@@ -18368,7 +18491,7 @@ var SELF_UPDATE_INTERVAL_MS = 60 * 60 * 1e3;
|
|
|
18368
18491
|
var SELF_UPDATE_VIEW_TIMEOUT_MS = 3e4;
|
|
18369
18492
|
var SELF_UPDATE_INSTALL_TIMEOUT_MS = 18e4;
|
|
18370
18493
|
function currentCliVersion() {
|
|
18371
|
-
return true ? "2.61.
|
|
18494
|
+
return true ? "2.61.27" : null;
|
|
18372
18495
|
}
|
|
18373
18496
|
function runCmd(cmd, args2, timeoutMs) {
|
|
18374
18497
|
return new Promise((resolve8) => {
|
|
@@ -38361,7 +38484,7 @@ function checkChokidar() {
|
|
|
38361
38484
|
}
|
|
38362
38485
|
async function doctor(args2 = []) {
|
|
38363
38486
|
const json = args2.includes("--json");
|
|
38364
|
-
const cliVersion = true ? "2.61.
|
|
38487
|
+
const cliVersion = true ? "2.61.27" : "0.0.0-dev";
|
|
38365
38488
|
const apiBase2 = resolveApiBaseUrl();
|
|
38366
38489
|
const diagnosticId = (0, import_node_crypto13.randomUUID)();
|
|
38367
38490
|
log.info("doctor", `run id=${diagnosticId} cli=${cliVersion}`);
|
|
@@ -38872,7 +38995,7 @@ async function mcpRun(args2) {
|
|
|
38872
38995
|
// src/commands/version.ts
|
|
38873
38996
|
var import_picocolors15 = __toESM(require("picocolors"));
|
|
38874
38997
|
function version2() {
|
|
38875
|
-
const v = true ? "2.61.
|
|
38998
|
+
const v = true ? "2.61.27" : "unknown";
|
|
38876
38999
|
console.log(`${import_picocolors15.default.bold("codeam-cli")} ${import_picocolors15.default.cyan(v)}`);
|
|
38877
39000
|
}
|
|
38878
39001
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "codeam-cli",
|
|
3
|
-
"version": "2.61.
|
|
3
|
+
"version": "2.61.27",
|
|
4
4
|
"description": "Workflow-continuity bridge for AI coding agents. Wrap Claude Code or Codex in a PTY and supervise, approve, and redirect the session from any device — async. The terminal companion for CodeAgent Mobile.",
|
|
5
5
|
"type": "commonjs",
|
|
6
6
|
"main": "dist/index.js",
|