ZSDev/obsidian-connor

Watch

Fork 0

Card 466 is built: the plugin's settings now have a Mint token button next to the "Connor plugin token" field, and the version is 0.4.4. (+82/−34, +0 mod) #28

Merged

Connor merged 1 commit from build/6542a038 into main

2026-10-25 22:38:56 +00:00

Connor commented

2026-10-25 22:37:01 +00:00

Owner

What changed

code: 3 source files in src/; 4 files; 3 test files in test/; 1 more kind(s) (+199/−48)

build/6542a038 → main — 11 file(s), +199/−48.

source: 3 file(s), +82/−34
other: 4 file(s), +6/−5
tests: 3 file(s), +96/−0
docs: 1 file(s), +15/−9
README.md
manifest.json
package-lock.json
package.json
src/lib/auth.ts
src/main.ts
src/settings.ts
test/api.test.ts
test/settings.test.ts
test/stubs/plugin.ts
versions.json

Growth

source: +82/−34 (net +48; budget +600)
modules: +0/−0 (budget +1)
test files added: 0; migrations: 0; evidence (screenshot/capture, not source): 0; not counted: 1
within budget

Why

Joel, card 466 is built: the plugin's settings now have a Mint token button next to the "Connor plugin token" field, and the version is 0.4.4. The whole gate (npm run gate: type-check, build verify, then the tests) ran green with 304 tests passing. It ships once you've reviewed it.

What the button does. It sends POST /vault/token with {vault, label: "obsidian plugin"}. The vault is the plugin's own Vault name setting, the same slug it sends to /vault/register and /vault/connect. The request always goes out on the cookie session, even when an old token is already in the box, because the server refuses a plugin token on that route. If the cookie can't be read, it falls back to the usual credentialed fetch. On success the token goes into the setting, gets saved, the link reconnects with it, and the settings pane redraws so the box holds it. A 401, a 403, a redirect, or a reply that turns out to be the sign-in page all bring up "Connor: sign in through the Connor panel first, then press Mint token". Any other refusal shows the server's own wording, such as "no vault 'v' registered for you". Nothing logs the token, and the success notice doesn't show it.

Which main I built on. I have no git or forge access in this run, so I couldn't read main's head on the forge. This working copy is main at 91a1331, which is the merge of card 465's PR #27, and it was already at 0.4.3. I bumped to 0.4.4 in all four version files. If main has moved past 0.4.3 since, the bump needs redoing. […]

Gate

npm run gate ran 304 tests in 4.5s and exited 0 — green.

Flow engine

⚠ Not reviewed by the flow engine. The engine errored, so this change took the direct path: no flow engine command is set (flow.route_command)

Built by Connor's frontend backburner (dispatch 6542a038) in an isolated clone; shipped deterministically by ship.py. The full build notes were spoken in conversation and stored in memory (agent-dispatch:6542a038). Review is the gate.

The brief this build was given

Kept for provenance. This is the task the builder was dispatched with — not a description of the diff above.

Requested: Card 466. First check main on the forge, not a stale copy: card 465's PR may already have bumped the version to 0.4.3. Add a "Mint token" button beside the existing "Connor plugin token" settings field (card 463). On click, while the plugin is signed in through the normal cookie path, POST /vault/token with JSON {vault: <this vault's registered name, the same one the plugin already sends to /vault/register or /vault/connect>, label: "obsidian plugin"}. The server is in connor/vaulttoken.py: it is a signed-in route, not a plugin route, so it has to use the cookie session. It replies {token, id, ...}, and the token is shown only in that reply. Save the token into the setting, persist it, and reconnect with it. If the request gets 401/403 or a redirect to sign-in, show a Notice like "Sign in through the Connor panel first, then press Mint token". Never log the token. Bump the version past whatever main has now so the self-updater offers it, and update the README token section to say "press Mint token". Tests for success, signed out, and the token not being logged.

### What changed code: 3 source files in src/; 4 files; 3 test files in test/; 1 more kind(s) (+199/−48) `build/6542a038` → `main` — 11 file(s), +199/−48. - **source**: 3 file(s), +82/−34 - **other**: 4 file(s), +6/−5 - **tests**: 3 file(s), +96/−0 - **docs**: 1 file(s), +15/−9 - `README.md` - `manifest.json` - `package-lock.json` - `package.json` - `src/lib/auth.ts` - `src/main.ts` - `src/settings.ts` - `test/api.test.ts` - `test/settings.test.ts` - `test/stubs/plugin.ts` - `versions.json` ### Growth - source: +82/−34 (net +48; budget +600) - modules: +0/−0 (budget +1) - test files added: 0; migrations: 0; evidence (screenshot/capture, not source): 0; not counted: 1 - within budget ### Why Joel, card 466 is built: the plugin's settings now have a **Mint token** button next to the "Connor plugin token" field, and the version is 0.4.4. The whole gate (`npm run gate`: type-check, build verify, then the tests) ran green with 304 tests passing. It ships once you've reviewed it. **What the button does.** It sends `POST /vault/token` with `{vault, label: "obsidian plugin"}`. The vault is the plugin's own Vault name setting, the same slug it sends to `/vault/register` and `/vault/connect`. The request always goes out on the cookie session, even when an old token is already in the box, because the server refuses a plugin token on that route. If the cookie can't be read, it falls back to the usual credentialed fetch. On success the token goes into the setting, gets saved, the link reconnects with it, and the settings pane redraws so the box holds it. A 401, a 403, a redirect, or a reply that turns out to be the sign-in page all bring up "Connor: sign in through the Connor panel first, then press Mint token". Any other refusal shows the server's own wording, such as "no vault 'v' registered for you". Nothing logs the token, and the success notice doesn't show it. **Which main I built on.** I have no git or forge access in this run, so I couldn't read main's head on the forge. This working copy is main at 91a1331, which is the merge of card 465's PR #27, and it was already at 0.4.3. I bumped to 0.4.4 in all four version files. If main has moved past 0.4.3 since, the bump needs redoing. […] ### Gate `npm run gate` ran 304 tests in 4.5s and exited 0 — green. ### Flow engine > ⚠ **Not reviewed by the flow engine.** The engine errored, so this change took the direct path: no flow engine command is set (flow.route_command) Built by Connor's frontend backburner (dispatch `6542a038`) in an isolated clone; shipped deterministically by `ship.py`. The full build notes were spoken in conversation and stored in memory (`agent-dispatch:6542a038`). Review is the gate. --- ### The brief this build was given _Kept for provenance. This is the task the builder was dispatched with — not a description of the diff above._ > Requested: Card 466. First check main on the forge, not a stale copy: card 465's PR may already have bumped the version to 0.4.3. Add a "Mint token" button beside the existing "Connor plugin token" settings field (card 463). On click, while the plugin is signed in through the normal cookie path, POST /vault/token with JSON {vault: <this vault's registered name, the same one the plugin already sends to /vault/register or /vault/connect>, label: "obsidian plugin"}. The server is in connor/vaulttoken.py: it is a signed-in route, not a plugin route, so it has to use the cookie session. It replies {token, id, ...}, and the token is shown only in that reply. Save the token into the setting, persist it, and reconnect with it. If the request gets 401/403 or a redirect to sign-in, show a Notice like "Sign in through the Connor panel first, then press Mint token". Never log the token. Bump the version past whatever main has now so the self-updater offers it, and update the README token section to say "press Mint token". Tests for success, signed out, and the token not being logged.

Joel was assigned by Connor

2026-10-25 22:37:01 +00:00

Connor added 1 commit

2026-10-25 22:37:01 +00:00

build: Card 466. First check main on the forge, not a stale copy: card 465's…

connor/growth lines 5,455 · headroom 68 of 400

gate / gate (pull_request) Successful in 10s

Details

b625016d62

Card 466. First check main on the forge, not a stale copy: card 465's PR may already have bumped the version to 0.4.3. Add a "Mint token" button beside the existing "Connor plugin token" settings field (card 463). On click, while the plugin is signed in through the normal cookie path, POST /vault/token with JSON {vault: <this vault's registered name, the same one the plugin already sends to /vault/register or /vault/connect>, label: "obsidian plugin"}. The server is in connor/vaulttoken.py: it is a signed-in route, not a plugin route, so it has to use the cookie session. It replies {token, id, ...}, and the token is shown only in that reply. Save the token into the setting, persist it, and reconnect with it. If the request gets 401/403 or a redirect to sign-in, show a Notice like "Sign in through the Connor panel first, then press Mint token". Never log the token. Bump the version past whatever main has now so the self-updater offers it, and update the README token section to say "press Mint token". Tests for success, signed out, and the token not being logged.

Built by my frontend backburner (dispatch 6542a038), diff verified by git; shipped by ship.py. Nothing merges without review.

Connor requested review from reviewer-bot

2026-10-25 22:37:02 +00:00

reviewer-bot approved these changes

2026-10-25 22:38:37 +00:00

reviewer-bot left a comment

Independent review — reviewer-bot (local model qwen2.5-coder:14b)

The PR adds a 'Mint token' button to the plugin settings, which sends a POST request to mint a new token. The implementation seems correct, but there are some suggestions for improvement.

Suggestions (non-blocking)

suggestion src/settings.ts:120 — The 'Mint token' button is added directly in the settings tab. Consider creating a separate method or component to handle this functionality for better code organization and reusability.
suggestion src/main.ts:360 — The 'mintToken' method is quite long. Consider breaking it down into smaller, more focused methods to improve readability and maintainability.
suggestion README.md:145 — The README mentions that the token is never logged, but it could be clearer about where the token is stored or how it is handled after minting. This might help users understand the security measures in place.

**Independent review — reviewer-bot (local model `qwen2.5-coder:14b`)** The PR adds a 'Mint token' button to the plugin settings, which sends a POST request to mint a new token. The implementation seems correct, but there are some suggestions for improvement. ### Suggestions (non-blocking) - suggestion `src/settings.ts:120` — The 'Mint token' button is added directly in the settings tab. Consider creating a separate method or component to handle this functionality for better code organization and reusability. - suggestion `src/main.ts:360` — The 'mintToken' method is quite long. Consider breaking it down into smaller, more focused methods to improve readability and maintainability. - suggestion `README.md:145` — The README mentions that the token is never logged, but it could be clearer about where the token is stored or how it is handled after minting. This might help users understand the security measures in place.

Connor merged commit 5a9ed7368a into main

2026-10-25 22:38:56 +00:00

Connor deleted branch build/6542a038

2026-10-25 22:38:56 +00:00

Connor referenced this pull request from a commit

2026-10-25 22:38:57 +00:00

Merge pull request 'Card 466 is built: the plugin's settings now have a Mint token button next to the "Connor plugin token" field, and the version is 0.4.4. (+82/−34, +0 mod)' (#28) from build/6542a038 into main