@pushary/agent-hooks 0.64.3 → 0.65.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.
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,40 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.65.0
|
|
4
|
+
|
|
5
|
+
### The pairing QR now works when you scan it with your phone camera
|
|
6
|
+
|
|
7
|
+
It did not. Scanning it opened the app on "Unmatched Route", and the only way
|
|
8
|
+
through was the in-app scanner, which parses the QR itself and never routes.
|
|
9
|
+
|
|
10
|
+
The QR encoded `https://pushary.com/app/pair`, and `/app/*` is claimed by the
|
|
11
|
+
app: the AASA lists it and so does the Android manifest. The OS therefore handed
|
|
12
|
+
the link to the app before the page could load, which was the intent. What it
|
|
13
|
+
handed over was the path `/app/pair`, and the app's pairing screen is `/pair`.
|
|
14
|
+
Nothing matched, on every build ever shipped.
|
|
15
|
+
|
|
16
|
+
The QR points at `/pair` now. Nothing claims it, so the browser always opens it,
|
|
17
|
+
and the page hands off to `pushary://pair`, which every shipped build already
|
|
18
|
+
routes correctly. That is the whole reason for the move: the Android claim is
|
|
19
|
+
compiled into the installed app, so no amount of server or app-store work fixes
|
|
20
|
+
the phones already out there, and this does, today.
|
|
21
|
+
|
|
22
|
+
`/app/pair` still serves the same page, so a link from an older CLI is not dead.
|
|
23
|
+
|
|
24
|
+
## 0.64.4
|
|
25
|
+
|
|
26
|
+
### The shell you ran setup in still exported the key it replaced
|
|
27
|
+
|
|
28
|
+
0.64.3 stopped a stale export from hiding the working key on disk, and the rc
|
|
29
|
+
file has been rewritten in place since 0.62. Neither reaches the shell you are
|
|
30
|
+
standing in: the export there is still the old key, the environment wins over the
|
|
31
|
+
config file at hook time, and the agent you start in that terminal a minute later
|
|
32
|
+
talks to whichever workspace that key belongs to.
|
|
33
|
+
|
|
34
|
+
`--connect app` mints on every run and is the command onboarding prints, so this
|
|
35
|
+
is the ordinary case rather than an exotic one. Setup now says so under "Still to
|
|
36
|
+
do": open a new terminal, or re-export. No key is printed in that line.
|
|
37
|
+
|
|
3
38
|
## 0.64.3
|
|
4
39
|
|
|
5
40
|
### A stale shell export hid the working key on disk
|
|
@@ -45,7 +45,7 @@ import {
|
|
|
45
45
|
connectViaAppPairing,
|
|
46
46
|
printConnectInstructions,
|
|
47
47
|
setHumanStream
|
|
48
|
-
} from "../chunk-
|
|
48
|
+
} from "../chunk-LZLXTM7P.js";
|
|
49
49
|
import "../chunk-3EGEA4KH.js";
|
|
50
50
|
import {
|
|
51
51
|
KEY_FILE_MODE,
|
|
@@ -1296,6 +1296,11 @@ var main = async () => {
|
|
|
1296
1296
|
markStep("save-key");
|
|
1297
1297
|
const rc = await saveApiKey(trimmedKey);
|
|
1298
1298
|
const context = { rc };
|
|
1299
|
+
if (envKey && envKey !== trimmedKey) {
|
|
1300
|
+
noteManual(
|
|
1301
|
+
`This shell still exports the previous key (${keyPrefix(envKey)}), and it wins over the one just saved. Open a new terminal before starting an agent here, or re-export PUSHARY_API_KEY.`
|
|
1302
|
+
);
|
|
1303
|
+
}
|
|
1299
1304
|
const failed = [];
|
|
1300
1305
|
const completed = [];
|
|
1301
1306
|
const skipped = [];
|
|
@@ -490,7 +490,7 @@ var buildPairLinks = (pairId, publicKeyB64, baseUrl = apiBase()) => {
|
|
|
490
490
|
const id = encodeURIComponent(pairId);
|
|
491
491
|
const pk = encodeURIComponent(publicKeyB64);
|
|
492
492
|
return {
|
|
493
|
-
universalLink: `${baseUrl.replace(/\/+$/, "")}/
|
|
493
|
+
universalLink: `${baseUrl.replace(/\/+$/, "")}/pair?id=${id}&pk=${pk}`,
|
|
494
494
|
deepLink: `pushary://pair?pk=${pk}&id=${id}`
|
|
495
495
|
};
|
|
496
496
|
};
|