Documents that gh issue comment create/delete, close, reopen, update,
edit, and board-row all now accept the owner/repo#number positional
shorthand that gh issue read/view and gh pr * already accept, completing
the shorthand parity across the gh subcommand.
The companion code change (scripts/src/gh.ts) was committed in the
previous commit; this doc update adds the long-term reference for the
new behavior and links it to the HWLAB #621 CLI acceptance friction
that motivated it.
The HWLAB v0.2 #744 fix was originally committed directly to v0.2 instead
of going through the canonical feature branch + PR flow. This documents:
- the canonical v0.2 worktree + PR sequence (trans G14:/root/hwlab-v02
worktree add, fix/issue<N>-* branch, UniDesk CLI gh pr create/merge,
fixed repo git pull --ff-only)
- a bounded recovery procedure when a direct commit has already landed
on v0.2 (single-commit case, --force-with-lease, autostash preservation,
cherry-pick onto the existing worktree branch, re-merge through PR)
- the v0.2 CLI verification gap: no layout-browser smoke exists for
19666/19667 (dev-cloud-workbench-layout-smoke.mjs is hard-coded to
16666/16667), so closeout must combine web:check + web:build,
control-plane status --lane v02, and direct curl/grep probes against
19666/19667
Closes CLI friction observed during the #744 v0.2 fix process.
gh issue comment create/delete, close, reopen, update, edit, and board-row
all now accept the owner/repo#number positional shorthand that gh issue
read/view and gh pr * already accept. This removes the friction of having
to split shorthand into a separate --repo flag and a bare number, and
keeps error messages consistent with the existing shorthand validation.
Discovered during HWLAB #621 CLI acceptance: posting the acceptance
results to the issue required gh issue comment create pikasTech/HWLAB#621,
which previously failed with 'issue comment create must be a positive
integer' and forced a separate --repo flag.
The D601 provider-gateway egress proxy (127.0.0.1:18789) is a
WebSocket-tunneled CONNECT proxy to backend-core. Long npm downloads
(playwright tarball ~3MB, plus tarball streaming) trigger ECONNRESET
mid-install, which then compounds into ENOTEMPTY on the next npm
retry because the partial global install is not cleaned up. The
in-dockerfile retry loop (5 attempts) exhausts and the image build
fails at Step 12/37.
The build's --build-arg NO_PROXY only listed localhost / 127.0.0.1 /
::1 / host.docker.internal, so every npm fetch went through the
proxy. Direct curl tests from D601 to registry.npmjs.org succeed at
HTTP 200 with ~280 KB/s, well above what the WS tunnel can sustain
for multi-MB downloads.
Persist the fix in both D601 and G14 pipeline manifests by adding
registry.npmjs.org and .registry.npmjs.org to NO_PROXY so docker
build's npm install goes direct. The proxy is still used for apt-get
and any other traffic that doesn't match the expanded NO_PROXY list,
so unrelated egress continues through the provider-gateway.
Refs: #189
M2.7 and M3 are two parallel configs, not a primary/fallback pair.
Per user feedback, drop the language and any code that framed M2.7 as
a rollback target for M3.
- code-queue-supervision.md, microservices.md, windows-passthrough.md:
remove 'default/fallback' labels; spell out that M2.7 and M3 are
parallel, no auto-fallback, switching provider model is an explicit
ops action.
- scripts/src/code-queue.ts: modelTiers entries for M3 and M2.7 share
the same 'simple-low-risk' risk; rename
minimaxM2FallbackCandidate -> minimaxM27Candidate so the dry-run
command string no longer implies fallback semantics.
- scripts/code-queue-submit-routing-contract-test.ts: drop 'fallback'
wording in assertions and the 'model registry fallback' check label.
Refs: #189
Codex