f977d26fef8b7b9ed80079ef8f129bebba31186d
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Opus 5
|
f977d26fef |
a ratchet on hardcoded colour, and the docs to match
The three previous attempts at this job died of endlessness, not difficulty. Nothing stopped the next component arriving with its own `text-emerald-400` while an old one was being fixed, so the number never fell for long. `bun run check:theme` counts palette classes per directory against a committed baseline. It does not care what the number is, only which way it moves. 942 across 21 directories today. Every directory can be paid down independently and none can quietly regrow — which turns an infinite job into a finite one. A baseline rather than a ban, deliberately: a rule forbidding palette classes outright fails on its first run, and a check nobody can make pass is a check everybody turns off. Proven by adding one `text-emerald-400` and watching it fail with the directory, the delta, and what to use instead. ── Documentation, which is part of the work rather than after it ── `src/workspaces/theme/README.md` is new and is the contract: how to write a theme, all 84 declarations by family, why colours are unwrapped HSL triplets while surfaces are complete CSS values, why assets are quoted paths, and the rules for components. Start from Plain, not from Duck — every value you change is then one you decided about. `plugins/EXTRACTING-A-PLUGIN.md` gains a rule beside the others: a plugin never hardcodes a colour, and pays its debt down DURING the extraction. The counts are named there — Soulseek 313, Invoices 95, Wallet 68 — because "some colours" does not convey that it is two thirds of the platform's total. The kickoff prompt says the same thing in the form a fresh agent will meet it. That is what makes the plugin exemption safe rather than a way of losing the work: the ratchet stops covering a directory the moment it leaves, so the rule has to travel with it. `THEMES-NOTES.md` rewritten to match reality — it still listed done things as open. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
df92a985d2 |
build failures say what went wrong
Every failed frontend build has reported `Bundle failed` and nothing else, for as long as anyone remembers. The cause is one line that was never there: `Bun.build` THROWS on failure by default. It throws an `AggregateError` whose own message is the string "Bundle failed" and whose `errors` array holds the real diagnostics. So the carefully written `result.success` branch — with its comment about what a failed build must not do — was unreachable, and the catch dutifully reported `err.message`. `throw: false` makes the returned result carry `logs`, which is what the code below it always assumed. The catch keeps a fallback that unpacks `AggregateError.errors` anyway: the build should no longer throw, and the failure mode this hides is exactly the one that has been wasting people's evenings. Truncation went 500 -> 1000 characters. A single bundler diagnostic with a file, a line and a code frame routinely exceeds 500, and cutting mid-path leaves it unactionable. Proven by breaking the app on purpose: before: Bundle failed after: ResolveMessage: Could not resolve: "./this-module-does-not-exist" ── The first attempt at that proof was worthless ── An UNUSED import reported `ok: true`, which briefly looked like a much worse bug — a broken app building clean. It is not: an unused import is elided by the TypeScript transform before anything tries to resolve it, so there was no error to report. The break only becomes a break once the import is used. Worth recording because "I broke it and the build passed" is an alarming sentence to arrive at by accident. Also verified that a failed build leaves `build/` alone — the staging swap does what its comment claims, so a bad build cannot take the running app down with it. This one shows up in the UI too: the Rebuild button in Settings -> System already displays `error`, so it stops saying "Rebuild failed" and starts naming the file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
997f7e7a87 |
the account stores a theme, not a colour mode
Your theme now follows the account instead of living in one browser's localStorage.
Choosing Plain on a laptop reaches the phone.
`appearance.colorMode` is superseded by `appearance.theme`. Along the way this
resolves a mismatch that had been sitting there: the server's default was
`appearance: { theme: 'light' }` while the client read `appearance.colorMode`, so that
default had never once been read by anything. Both sides say `theme` now.
The Light/Dark item is gone from the user menu. Light and dark are two themes, both
already in the list above it, and that toggle was the last writer of the legacy key.
── Two bugs found by testing this, both mine, both silent ──
**A default that looked like a choice.** `useSettings` returns `DEFAULT_SETTINGS`
until the request lands — `settings` is never null, it is a complete valid object. So
"wait for settings" fired on the first render against the defaults, marked itself
done, applied the default theme and never saw the real one. Then the persist side
wrote that default over the account's actual preference. It overwrote the owner's own
`dark` while I was testing it; restored by hand from the `colorMode` it had not yet
destroyed. `useSettings` now exposes `settingsLoaded` so the difference is expressible.
**Defaults masking a migration.** With that fixed, an account holding only
`colorMode: 'dark'` STILL came up light. The client merges `DEFAULT_SETTINGS` over
whatever arrives, so a missing `theme` is filled in with the default before any
consumer sees it — and a default is indistinguishable from a choice. The migration
therefore belongs on the SERVER, which sees the stored object before anything is
merged over it. It is read-only: a GET that rewrites the row on every call is a
surprise, and the client persists on its next change anyway.
Verified by putting the account into the pre-themes shape and asking the new handler
directly, rather than by restarting to find out:
stored: {"colorMode":"dark"} -> returned: {"colorMode":"dark","theme":"duck-dark"}
── Needs a restart ──
The first server-side change in this work. Everything until now was frontend and a
rebuild was enough.
950 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
ecb6864ff9 |
delete the landing app
Built and shipped from somewhere else now, so this copy was dead weight that still carried its own third copy of the palette — `duck-teal` had three different definitions across three apps, and this was one of them. Removed: `src/apps/landing`, `scripts/build/landing.ts`, the `build:landing` script, and the tree entry in CLAUDE.md. `/landing-page-data` STAYS and is unrelated despite the name — it is the API the sign-in screen asks whether registration is open. Worth saying because a grep for "landing" hits both and only one of them was meant. Nothing imported from the app. tsgo clean, frontend builds, the live app serves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
12f1e93c4a |
panels are a themed surface, not three literal rgba pairs
The cornerstone of the layout was the least themeable thing in it. Measured before touching anything, which is the only reason this is the right fix: duck-dark radius=8px bg=rgba(255,255,255,0.12) border=rgba(0,0,0,0.25) blur=24px plain radius=0px bg=rgba(255,255,255,0.12) border=rgba(0,0,0,0.25) blur=24px So the RADIUS was already following `--radius` and I had been telling the owner otherwise — the rounding in the Plain screenshot was something else. What did not follow anything was the surface: three literal rgba pairs and a fixed `backdrop-blur-xl` in the component. Now: plain radius=0px bg=rgb(255,255,255) border=rgb(0,0,0) blur=0px Two distinctions the old code drew in literals are kept as tokens rather than flattened, because both are real and a theme should be able to revisit them. `--panel-raised-*` is the fullscreen surface: DENSER glass, not darker, because panel chrome is dark text and a heavy dark fill hid every icon. `--panel-border-bare` is for a panel with no header, which has nothing else separating it from what it sits on. `--panel-blur` earns its place beyond theming: a flat theme was paying for a 24px backdrop blur it did not want, and on a solid panel the compositor does that work for nothing. ── A near miss worth recording ── The first attempt silently changed nothing. The patch matched on four spaces of indentation where the file has two, `str.replace` reported no error, the build succeeded, and `panel-blur` DID apply — so the class landed while the surface did not. It looked like a partial success and would have shipped as one. Caught by measuring computed styles again rather than trusting the edit; the fix now asserts the replacement changed the file. 950 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
dfb8a6d6cb |
a sixth tone, and no raw palette left in the core apps
The five core apps — FileBrowser, FileViewer, SystemMonitor, Chat, Plugins — now contain ZERO raw Tailwind palette classes. Every colour in them names a state or a surface, so all of it follows the theme. ── Busy ── The 38 ambers were the blocker, and the answer was not to pick between two wrong mappings. They mean RUNNING — Chat's own comment says "the amber a RUNNING task chip wears" — and the vocabulary had no word for it. `warning` would have made a working job look like a failing one, and `--status-in-progress` is blue. So `tone.ts` has six tones instead of five. It was always written as a closed set that could grow when a genuine sixth state appeared; this is that. `--busy-ink` comes with it, and generalises: a fill bright enough to carry black text is far too light to BE text. The other five tones are dark enough to do both jobs, which is why the problem had not surfaced. `text-amber-950` — ink ON the fill — became `text-busy-foreground`, which is what it always was. ── On fidelity, which stopped being the constraint ── Duck's exact colours were preserved up to this point because an extraction has to be provably invisible. The owner has since said the palette is not precious: the wallpaper, the graph-paper grid and the mark are what matter, and everything else can move. So shades collapse — one busy, one red, one green — rather than being approximated to keep old pixels. The verification built for the old constraint keeps its value: it proves the token layer resolves, which is a different claim from "the colours did not change". Verified: the utilities compile (`text-busy-ink`, `bg-busy`, `border-busy`, `text-busy-foreground`) and resolve in the browser. 950 pass / 7 fail unchanged. tsgo clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a52d3e06f3 |
one red and one green, in the core apps
82 raw palette classes in FileBrowser, FileViewer, SystemMonitor, Chat and Plugins now name a state instead of a colour. `docs/design-language-interface.md` has said to do this for a long time and `tone.ts` implements it; eight files were following it. Only the families whose semantic token IS the colour already in use: destructive #ef4444 == text-red-500 exact success #16a34a == text-green-600 exact So `red-500` and `green-600` are byte-identical renames, and the neighbouring shades (`red-400`, `red-600`, `green-500`, `emerald-500`) shift by a little on purpose — having one red is the point. Verified on screen, not just typechecked. Three greys became `muted-foreground`, which is what "quieter than the text" means here. ── Amber is deliberately untouched, and needs a decision ── 38 amber classes remain and a regex must not have them. They are not warnings. Chat's own comment says it plainly: "the amber a RUNNING task chip wears". It is a BUSY tone, and the token set has no such thing — `--status-in-progress` exists and is blue. Mapping them to `warning` would change both meaning and colour: Duck's `--warning` is #fbbd23 (amber-400) while the code uses amber-600 #d97706 as text and amber-950 as ink on a fill. Text at that lightness on white is not readable, and "running" would start looking like "something is wrong". Two ways out, both the owner's call: add a sixth tone for busy/queued, or accept warning's colour and meaning for it. ── Deliberately out of scope ── The plugin candidates — Soulseek 308, Invoices 95, Wallet 68, Jellyfin 48, Photos 47, Transmission 41 — are two thirds of the debt and are leaving this repository. Their colours belong to their extraction, when the rules exist and their imports are being rewritten anyway. White and black are also untouched: they are media overlays in the file viewer and photo surfaces, correct in every theme because they sit on someone's photograph rather than on a themed surface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a0013e4f28 |
note that theme asset packaging is deferred, not solved
A theme references its wallpaper and logo by path because the CSS bundler cannot resolve a runtime `public/` file at build time. That is fine for themes we ship and says nothing about where a third party's assets live. The owner's intent is a convention under `public/` — recorded so the workaround is not mistaken for a design. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
e9cb244818 |
the wallpaper, the header and the mark belong to the theme
Asked whether these could follow the theme too. They are the three most visible things
on screen and were the three least reachable: `Background.tsx` hardcoded
`url('/landscape1.webp')`, the header carried `rgba(255,255,255,0.25)` and `#1d2724`
in an inline style, and the logo was an `<img src>`.
Between them that is most of what "the app looks like Officer" actually meant. The
Plain theme turned every panel white and all three stayed exactly as they were, which
is how they were found — the leak detector doing its job on its first outing.
Verified across all three themes:
duck-dark wallpaper=landscape1.webp header=rgba(255,255,255,0.25)
duck-light wallpaper=landscape1.webp header=rgba(255,255,255,0.25)
plain wallpaper=none header=rgb(255,255,255)
── Images could not be done the obvious way ──
`--logo-image: url('/officer-logo.svg')` fails the build. Bun's CSS bundler resolves
`url()` at BUILD time and these files are served from `public/` at RUNTIME, so it goes
looking for a module that does not exist. Colours apply themselves; images cannot.
So a theme publishes a quoted PATH — an ordinary string token the bundler ignores —
and `useThemeAsset` reads it and wraps it in `url()`. One hook rather than the read
inline in two components, because the quote-stripping is the kind of detail that gets
forgotten the second time.
The logo is a `<div role="img">` with a background image rather than an `<img>`, since
CSS cannot set a `src` and a white-labelled build has to replace the mark from its
theme rather than by editing the header.
The header's title colour goes through a `.header-ink` class: `EditableTitle` accepts
a className and not a style, and the token stays the source of truth either way.
Panel radius and the ~985 raw palette usages are still outstanding — see
THEMES-NOTES.md.
tsgo clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
1be4bcd39a |
prove the extraction faithful, and fix the one thing that was not
The screenshots said seven dark screens differed and could not say why. Comparing COMPUTED theme variables between the old build and the new one, in the same colour mode, answered it in a single run: 47 of 53 matched exactly, and the six that did not were the `--duck-*` variables — EMPTY in the new build. The utilities were remapped to `--brand-primary`, `--ink` and friends, which is correct. What that missed is code reading the VARIABLE rather than using the utility. `prose.css` does exactly that eleven times — chat markdown links, blockquotes, inline code, checkboxes — and `landing/styles.css` does it six more. All silently resolved to nothing. Fixed by keeping the legacy names as aliases in every theme, pointing at the new source of truth rather than duplicating values. That also covers any plugin or inline style doing the same thing, which I have not enumerated. They retire when the utility rename lands. Every variable now matches. ── What the screenshots are actually worth here ── Less than I assumed. The wallpaper rotates per page load, so a control capture of the same build against itself had 4 of 16 screens differ — and a different 4 each time. Between 5 and 6 come out byte-identical to the baseline on any run; the rest is noise I mistook for signal for two rounds, including one where I removed a `color-scheme` line to test a theory it turned out not to explain. The variable diff is the instrument that settles it, and it is cheap. Added as `scripts/theme-vardiff.ts`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
105766a4eb |
extract the visual layer into its own workspace
The application no longer knows what it looks like. It imports one stylesheet and
mounts one provider; every colour, surface and radius lives in `src/workspaces/theme`.
Proven both directions, because either alone would be worthless:
Duck renders IDENTICALLY to before — checked against screenshots taken before
anything was touched, not asserted.
Plain renders as white with black ink, no component edits — panels turn white, the
teal avatar turns black, the grid fills vanish.
── What moved ──
`globals.css` held three unrelated things: Tailwind wiring, the token contract, and
the Duck brand's hex values. Split along those seams. `base.css` is structure and
names no colour; a theme file is values and nothing else, scoped to
`[data-theme='<id>']`. Adding a theme is a CSS file plus one registry line.
Light and dark are separate themes rather than a mode — the owner's call, and it
removes a concept from the app. Each is written out in full: a theme that only makes
sense as a diff against another cannot be authored by a stranger or sold to a
customer. `.dark` survives only as a per-theme flag, because 396 `dark:` utilities in
33 components resolve against it; retiring those retires the flag.
The `duck-*` utility names are kept for now and pointed at neutral variables, so a
non-Duck theme can define them sensibly. Renaming 1,470 occurrences in the same commit
as the extraction would make any visual difference impossible to attribute. Worth
recording that `duck-dark` was never a brand colour — `#14532d` in light, near-white
in dark, used by 946 components to mean "text". It is `--ink` now.
Surfaces are complete CSS values rather than HSL triplets: `--panel-bg` has to be able
to be a gradient or an image, or the glass the app already has would be unthemeable.
The old provider is a re-export, so its six call sites are untouched and the
extraction stays one variable.
── Bug found by the Plain theme ──
`useThemeSync` stamped the server's `appearance.colorMode` over the local theme on
every load, so choosing Plain and reloading silently reverted it. Diagnosed by asking
the page what it was wearing rather than reasoning: `stored` said `duck-dark` when the
script had written `plain`. The server value is now a starting point for a browser
that has never chosen, not a continuous instruction.
── Tools ──
Two, both of which lied to me before they worked. The snapshot script photographed
light twice and called it a clean run (one browser context, accumulated init scripts);
it now warns when a light/dark pair is identical. The preview server returned the
shell for missing assets, so the logo and wallpaper vanished and read as regressions
in the comparison — it falls through to upstream now.
Dead Tailwind v3 residue deleted: `components/ui/tailwind.{config.ts,css}`, referenced
by nothing, with content globs pointing at a directory that does not exist.
── Not done, deliberately ──
`THEMES-NOTES.md` has the full list. The headlines: the reference repo has not been
read, so the switching mechanism is deliberately the dumbest thing that works; the
wallpaper, panel radius and logo are still component-owned and Plain proves it; and
~985 raw Tailwind palette usages remain, worst in Soulseek.
tsgo clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
7980ee3761 |
photograph the app before touching how it looks
The themes work moves every colour out of the components and into a token layer, and the entire value of that is being INVISIBLE. Nothing here could have told us whether that held: the tests do not render, and comparing two screens from memory an hour apart misses exactly the things this can break — a border colour, a radius, one mode of two. Eight routes, both colour modes, against the running app. Byte comparison rather than a pixel-tolerance diff: a false alarm costs opening two images, a false all-clear costs the refactor. The first version was worthless and looked fine. It reused one browser context and added an init script per mode — Playwright ACCUMULATES those, so the dark pass ran the light script too, and the class toggle after `goto` was undone by the provider's own effect. Six of eight routes came out byte-identical in light and dark, which reads as a clean run. A context per mode fixes it, the class is asserted after settling rather than before, and identical light/dark pairs now print a warning instead of passing quietly. Verified rather than assumed: 15 distinct images of 16, every route differs between modes, and one was opened to confirm it is the authenticated app and not eight variations of an error boundary. Baselines are gitignored — 7MB of machine-specific PNGs. Regenerate with the script. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
690a726f55 |
a member's turn ran as the owner after any idle gap
This is the cause. Everything before it was symptom.
`handleChat` had two spawn call sites. The first, for a new session, passed `member`.
The second — "session already live" — was a separate object literal that did not.
That branch is taken whenever OFFICER still holds the session, and officer holds it
long after the SIDECAR has let go: the sidecar reaps a session after 30 minutes idle,
`_claudeKill` stays set here regardless. So a gap sent a turn with no identity to a
sidecar with nothing to push it onto, and it created a fresh session from those
params. No member means the owner.
[claude:spawn:…] resume=49527b33… cwd=…/data/jg@pertento.ai/home as=owner
green is a Developer with their own Linux account, their own `claude` and their own
login. Every turn after a break ran as the OWNER: owner's HOME, owner's Anthropic
credential, owner's MCP config — which carries a JWT that signs as the owner. The
entire per-member boundary, undone by an omitted line in the branch nobody reads.
It surfaced as breakage rather than as silent escalation only by luck. The owner's
`claude` was handed the member's cwd — a 700 home it cannot enter — and the member's
transcript id, so it exited 1 instead of quietly working. Reported as "he went for a
walk and it stopped working", which is the idle timeout to the minute.
── The fix, and what it then found ──
Both paths now build from one `turnParams`, so they cannot drift again.
Then `member` was made REQUIRED-though-possibly-undefined in the protocol, and the
compiler immediately found three more sites that had left it out:
- `agent-handoff/deliver.ts` — the same bug, worse. No member AND a cwd from
`getOwnerHomeDir`, which ignores the email it is given. A member's agent panel ran
as the owner in the owner's home. Now resolves identity like chat does.
- `agents/agent-runner.ts`, `tasks/pipeline-executor.ts` — correct as they were:
both are `kind: 'execution'`, owner-only and never grantable. They now say
`member: undefined` explicitly, because a field you must fill in is a decision and
a field you may omit is an accident.
`resolveTurnIdentity` is exported so "whose turn is this" has one implementation
rather than three.
── What I got wrong on the way ──
Three wrong answers first — the credential, the working directory, then a recovery
whose condition could never fire — each from reading code and reasoning instead of
making the system say what it was doing. The log line that found this took five
minutes to write and should have been the first thing I did, not the fourth.
Also: `--resume` by hand appeared to work twice, which is what sent me down the wrong
paths. It proved nothing. The id I tested was not the id the platform passed.
tsgo clean, 950 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
9203472be8 |
the recovery could never have fired — fix its condition
Shipped
|
||
|
pastilhasandClaude Opus 5
|
e642205207 |
a chat that cannot be resumed stops being permanently dead
A member's conversation answered "Claude Code process exited with code 1" to every message, four times identically, and could never recover. A brand new chat worked throughout. Diagnosing it took an evening and produced two wrong answers — the credential, then the working directory — both disproved by hand on the server, because the one input most likely to be at fault appeared in no log anywhere. Three changes, and the first is the one that matters most next time. ── Say what is being run ── `[claude:spawn:<key>] resume=… cwd=… as=… model=…`, before the spawn. The resume id is NOT the id in the URL — it comes from a stored map, so the two can disagree, and nothing could previously show that they had. Every hypothesis about it had to be tested by hand. ── Carry the child's reason to the person who hit it ── stderr was logged and then dropped, so the client got a number. The tail is now kept on the session and travels with the exit, both to the log and to the user. When the child says nothing at all — which is what happened here — the sentence still reads, rather than trailing a dangling colon. ── Stop retrying a resume that cannot work ── `sawOutput` records whether the child ever produced a single message. False, on a turn that was resuming, means it never got as far as loading the conversation — and since a fresh chat works with the same process, account, credential and binary, `--resume` is the only input that differs. So the stored id is dropped and the next message starts clean. The history is lost to the agent, which is a real cost, and strictly better than a thread that can only ever return an error. Nothing reconsidered that id before, which is why four identical failures in a row was the floor rather than a phase. Deliberately NOT done when the child spoke first: that is a turn that broke halfway, the transcript is fine, and clearing it would trade one bad turn for an amnesiac conversation. That negative case is the second test. `diagnoseExit` is its own module because everything around it needs the SDK to construct — which is how the old single sentence went unexamined for so long. 8 tests. This does NOT explain why the resume failed; it makes the next occurrence say so instead of costing an evening. The cause is still open. tsgo clean, 945 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
b3b44ee77d |
changing route in a preview no longer reloads the app
Reported as "I change routes and a second later the whole app refreshes". The second
was mine: the 800ms debounce on writing the location down.
`DevProxyFrame`'s session effect had the composed URL in its dependency list. That URL
changes every time the app navigates, so the effect re-ran — and its first act is
`setReady(false)`, which swaps the frame for "Connecting…" and takes the iframe out of
the tree. Coming back mounted a fresh one. A full page load, one debounce after every
click.
Watching the URL was never right: the cookie is issued with `Path=/api/dev-proxy` and
no port in it, so it already covers every path and port the panel can reach. It now
depends on entering proxy mode and on an explicit reload, where re-requesting is the
whole point.
── A second bug, found while fixing the first, not yet reported ──
Freezing `src` at mount stopped the app's navigation from reloading the frame — and
also stopped a newly TYPED url from loading, because nothing remounted. The panel
would have silently ignored a change of address.
The two pull in opposite directions, which is what makes the pair the interesting
part rather than either fix. They are told apart by which value changes: `entry` moves
only when a person points the panel somewhere else, `target` moves when the app does.
So the frame is keyed on `entry` and loads `target`.
── The tests were made to fail first ──
Three component tests, and both bugs were re-introduced one at a time to check the
tests actually catch them:
URL back in the effect deps -> "the app navigating does NOT reload" FAILS
key back to reloadToken alone -> "a newly typed url DOES load" FAILS
Either bug alone would have been passed by a test written for the other, so they only
mean anything as a pair. Both were invisible to reading the component and obvious in
the DOM — the assertion is node identity across a rerender, which is the same question
as whether the browser re-requested the page.
`fetch` is stubbed and restored per test rather than `mock.module('hooks/useClient')`:
Bun has one module registry for the whole run, so that mock is process-wide and
permanent, and `useDashboardState.test.tsx` already owns it.
tsgo clean, 937 pass / 7 fail unchanged, frontend builds. Needs a rebuild — frontend
only, so the Rebuild button is enough; no restart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
d771736a0d |
the preview panel follows the app's navigation
The panel knew one URL: the one you typed. Navigate three pages into an app and the header still showed the front door, "open in a new tab" still went there, and a reload — which fires by itself whenever a dev server restarts — threw away where you were and started again at `/`. Now the app reports where it is, and a reload composes it back. ── How the panel finds out ── The frame is same-origin for a proxied preview, so `contentWindow.location` is readable. It is PUSHED rather than read, because a dev server is an SPA: a route change is `history.pushState`, which fires no event and never reloads the document. Polling would have to be constant and would still lag. The script the proxy already injects now patches `pushState`/`replaceState`, listens for `popstate`/`hashchange`, and posts the path — with the proxy prefix stripped, since that is plumbing and the panel should not have to know about it to show a URL. Only proxied previews can do this. A cross-origin frame reports nothing, and grafting a remembered path onto someone else's host would be inventing a URL, so `targetUrl` composes only when there is a port. ── Two fields, and the loop that forced them ── `url` is what you pointed the panel at; `current` is where it has got to. The obvious design is one field — a browser has one address bar — and it feeds itself: the stored value IS the iframe's `src`, so recording a route change hands the frame a new `src` for the page it is already showing, which browsers treat as a navigation. Every click would cost a reload. Belt and braces, because one of the two would be enough only until someone changed the other: the fields are separate, AND `PreviewFrame` captures its `src` at mount and ignores later changes. Remount-by-key is still how a reload happens. `ev.source` identifies which frame is talking. `message` is a window-level event and two same-origin previews hear each other; comparing the posting window to this iframe's `contentWindow` is exact, where matching on URL would break the moment two panels pointed at the same port. Writes are debounced 800ms. `useDashboardState.setValue` PATCHes the server on every call and an SPA emits a route change per click; the value is only read at mount, so being a second behind costs nothing. Also: the header shows `localhost:3001/settings` rather than `api/dev-proxy/3001/settings`, and editing starts from that — one is a thing you can retype, the other is not. ── Tests ── The reporter is RUN, not string-matched: `new Function` against a fake window, which also means a syntax error in the injected script fails the suite rather than silently breaking every proxied page. Covers prefix stripping, the app root reporting `/` rather than empty, query and hash surviving, the report on load, pushState, and popstate. Plus the composition helpers, including that an ordinary URL is never composed with a path. ── One stale comment corrected while in there ── The file claimed `allow-same-origin` "is present, and has to be". There is no `sandbox` attribute at all, so nothing was present — and a sandbox with `allow-same-origin` plus `allow-scripts` is worth roughly nothing anyway, since the frame can remove its own sandbox attribute. Now says that. Not verified against a live dev server through the real proxy — that needs the server restarted with this code. tsgo clean, 934 pass / 7 fail unchanged, frontend builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
430346e14b |
a restarted job outlives the server that restarted it
The other half of the same report. The pill came back after a refresh, and then a
`pm2 restart officer` killed the dev server outright — because `restartBackgroundTask`
spawned it as a plain child of the platform. A job the AGENT starts is a child of the
`officer-claude-code` sidecar, a PM2 peer, so those were never affected. The tray
therefore showed two chips that looked identical and behaved differently, and the
restart button's own help text promised the opposite of what happened.
Measured against a throwaway PM2 app rather than reasoned about, because the two
plausible causes call for different fixes — a signal to the process GROUP, or a walk
of the process TREE:
plain `sh -c` killed
`setsid sh -c` killed <- a new session is NOT enough
`setsid --fork sh -c` survived
PM2 walks the tree by ppid, so a new session leaves the job a child and it is found
anyway. `--fork` is what matters: setsid forks and its parent exits at once, so the
job is reparented to init before any restart can enumerate it.
── What that costs, and how it is paid ──
The handle `Bun.spawn` returns is now the setsid parent, which exits immediately.
Waiting on it reported every job as finished the moment it started, so exit detection
moved to `watchForExit`: poll who holds the output file, and when nobody does, read
the status the wrapper recorded. That is the same liveness question Stop and Pause
already ask, so it adds no second notion of "running" — and a paused job still holds
its file, so SIGSTOP correctly reads as running rather than as an exit.
Two details that would each have been a bug:
- A GRACE PERIOD. Between the fork and the job opening its output there is a moment
with no holders; polling into it announces a completion for a job that never ran.
- The command is a POSITIONAL PARAMETER to the wrapper, not interpolated into it.
Interpolation would let a command containing quotes terminate the wrapper's own
quoting. Tested with `echo "quoted 'both' ways"`.
A missing status file is reported as a clean finish, not a failure: that is what Stop
looks like, and "you stopped it" is nearer the truth than "it crashed".
Also corrected the button text. It said background jobs survive "because they are
their own PM2 processes" — true of agent-started jobs, false of restarted ones, and
now the wrong reason for both. They survive because they are outside this process's
tree.
── Verified ──
End-to-end through `buildHonoApp`, on a synthetic task:
POST /restart -> 200
holders: pid 906186 (ppid 1, session leader), pid 906188 (ppid 906186)
probe process was 906173 — in neither chain
quotes survived the wrapper
durable events: task:started -> task:notification (completed), exit file "0"
My own assertion in that probe was wrong and the output is what corrected it: it
demanded ppid 1 of EVERY holder, but only the session root is reparented — its own
children hang off it, which is the point.
Not in `bun test`: nothing in the suite touches Postgres or spawns processes.
tsgo clean, 919 pass / 7 fail unchanged. Needs a server restart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
b7d26a3350 |
a restarted background job survives a refresh
Reported as "I refreshed the page and the pill was gone, but the server is still
running and now I have no way to control it". Not a design choice — a bug, and it
came in with the restart button.
The tray is not stored anywhere. It is a fold over the durable chat event log:
`task:started` minus `task:notification`, per `collectRunningTasks`. That is what
rebuilds it after a refresh.
The restart route announced its respawn with `emitToSession`, which folds into the
in-memory session and writes to open sockets — and never called `appendChatEvent`.
So the pill existed only in the RAM of the browser tab that clicked the button. The
log still read:
seq 10979 task:started "Run dev server"
seq 11362 task:notification failed <- the ORIGINAL dying
Folded on refresh that says "not running", so the chip vanished — while the process
it described was up and serving on 3001. And every task route takes an id, so the
job became unreachable from the UI at the moment the browser forgot the id. Stop,
Pause and Restart would all still have worked; nothing could name the task.
The second half was quieter: `emitToSession` returned false when the session was not
in memory, and the route ignored the return. A platform restart drops the in-memory
session while the job keeps running, so the announcement went nowhere AND was never
written down.
Now it appends first and unconditionally — persistence does not need a listener,
only delivery does — and sends with the seq the log assigned, so a client's replay
cursor stays correct. Both events: the `task:started` is awaited so it is durable
before the client is told the restart worked, and the exit notification is
fire-and-forget because it lands long after the response.
This makes officer a writer of `chat_session_events`, which the note in websocket.ts
said it no longer was. `cut-off` had already been that exception. The real rule is
narrower and is now written down: officer writes events it ORIGINATES, because no
sidecar will. Turn output still belongs to the harness that produced it.
── How it was verified ──
End-to-end, out of band: a synthetic task with a real process holding a real output
file, a transcript in the harness's shape, and the two durable events that reproduce
the reported log. Driven through `buildHonoApp` so the permission gate and auth
middleware were in the path — the last two bugs of this kind both passed tests that
mounted the router alone.
BEFORE restart: 2 durable events -> tray would show 0 running (bug reproduced)
POST /restart -> 200
AFTER restart : 3 durable events -> tray would show 1 running
Not added to `bun test`: nothing in the suite touches Postgres, and this claim is
untestable without it. So this is a probe that ran once, not coverage.
Needs a server restart. tsgo clean, 919 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
eaa38c7d43 |
the maintenance buttons tell you when they fail
Asked whether there was feedback on failure, and for the restart there was not —
there was the opposite.
`useClient` throws on any status >= 400. The restart handler caught everything and
reported success, on the reasoning that a dropped connection is normal when the
process answering the request is the one being replaced. That is true, and it made
the honest refusal built into the route unreachable: a 400 saying "not running under
PM2" arrived through the same catch, so the button would have said "Restarting…"
while nothing restarted, and stayed disabled forever.
The two failures are opposites and are now told apart by whether an error carries a
STATUS. A status means the server answered and declined — real error, message shown,
button re-enabled. No status means the connection dropped — expected, and the
success path.
Both buttons also unwrap the message. The client throws with the raw response body,
and these routes answer with JSON, so an unhandled failure showed
`{"ok":false,"error":"…"}` and asked the reader to find the sentence inside the
punctuation. Five tests on that, including the cases where it must NOT invent one:
JSON with no error field, and a non-Error thrown value.
Found while answering the question rather than by testing, which is the wrong order.
── One thing I should not have done ──
I exercised the restart route against the live server to see its refusal shape. PM2
knows `officer` here, so it returned 200 and scheduled a real restart; the only
reason it did not happen is that my test process called `process.exit(0)` before the
250ms timer fired. Luck, not design. `pm_uptime` confirms the platform never
restarted.
tsgo clean, frontend builds, 919 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
1426c3a856 |
rebuild the frontend without restarting, and restart when you must
Settings → System → Maintenance. Two buttons that are deliberately not a pair. ── Rebuild: real, and free ── The same `rebuildFrontend` a plugin install already runs. `Bun.build` reads source from disk on every call and writes `build/`, and the server serves that directory by reading each file per request — so a rebuild lands on the next page load with no process restart, no dropped websocket and no chat session lost. ── Restart: the only way to load server code, and it costs ── Bun caches modules for the life of the process. Measured rather than assumed: editing a file and re-importing returns the ORIGINAL export, and a cache-busting query picks up that one specifier while everything it imports stays cached. So `rebuildHonoApp` — which install already does — re-wires the same module instances into a new tree and cannot see a backend edit. Busting the whole graph would duplicate singletons: two database clients, two session maps, one process. There is therefore no third button, and the screen says why. A "remount the API" control would look like it reloaded the backend and would not. The restart answers BEFORE it schedules itself, because the process serving that request is the one being replaced. It refuses outright when PM2 does not know this process — in development the platform runs under `bun --watch`, where the restart would fail into a promise nobody awaits while the button reported success. Verified: `POST /rebuild-frontend` → 200, 3.0s, 3 outputs; anonymous → 401. The restart button is deliberately untested from here — pressing it would end the session this was written in, which is the same reason it needs a label that says so. tsgo clean, frontend builds, 914 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
e8eea2b677 |
setup installs poppler, or an attached PDF cannot be read
Reading a PDF attachment needs `pdftoppm`. It was not installed on this machine and is not in any package list, so the first real PDF attachment failed at the last step — uploaded fine, landed on disk fine, unreadable. That failure reads as the feature being broken rather than a package being absent, which is the worst shape for something a fresh install would hit on its first try. Added to all four managers: `poppler-utils` on apt and dnf, `poppler` on pacman and brew. Worth recording WHY it is needed, because it is not obvious: the agent reads a PDF by RENDERING its pages, not by extracting text. On the document that prompted this — a sitemap of tree diagrams and wireframes — extraction returns almost nothing and rendering returns everything. The dependency is on the approach that works. Installed on this machine by hand already; this is so the next one has it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
92bac490d7 |
attach a PDF and the agent reads it; the microphone button is gone
Two requests, one file apart. ── The microphone ── Removed from the chat composer. The HOOK stays: `useAudioRecording` and `blobToWav` are also the file browser's DictateDialog, which is not what was asked to go. ── PDFs, by not extracting anything ── A PDF entry sat in the attach menu once with no `onSelect` at all — the menu offered it and did nothing, because nothing here could extract PDF text. It is back and real, and it still extracts nothing: the file is uploaded, left on disk, and the agent is given its PATH. Its own `Read` handles PDFs by page, better than any extraction this could have shipped, and it can go back for a section later without paying for it twice. The alternative was base64 in the message. That is megabytes in the turn, re-sent for the rest of the conversation, to produce worse text. ── What this uncovered ── `attachmentIds` has been on this websocket and in `types.ts` for a long time and NOTHING on the server read it. Images work because they travel separately as base64, so the ids were dead on the wire — and a PDF is exactly the case that needs them. They resolve to paths now, appended to the prompt as `Attached files (read from disk)`. Ids arrive in a websocket message and become a filesystem path, so they are checked rather than trusted: only the `<uuid>.<ext>` shape uploads actually generate, and only in the two directories uploads actually write to. Verified — a valid id resolves, an unknown one yields nothing, and `../../../../etc/passwd` and `; rm -rf /` yield nothing. Both upload directories are searched because the first message of a chat carries ids written to `tmp/` (no session yet) and later ones carry ids under the session. PDFs may be 25 MB against an image's 5: nothing carries them into a prompt, so the ceiling is storage rather than context. tsgo clean, frontend builds, 914 pass / 7 fail unchanged. `[open]` For a MEMBER the file lands under `data/<email>/attachments/`, and whether their Linux user can read it depends on the confinement ACLs. Untested — the owner path is what was verified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f4f8ea32d1 |
a paused job shows a pause icon, not a spinner
The details panel kept spinning after Pause, so a frozen dev server looked like a working one. The spinner is the whole claim being made, and it was false — the state most likely to be watched, since the panel is where you sit while a `bun dev` runs. Amber either way: it is still a live job holding its port and its memory, which is what separates paused from stopped. What changes is the motion, and the line beside it now reads `paused` rather than `running…`. ── And the state moved up a level ── `paused` lived in the panel, which unmounts when you close it. Closing and reopening would have put a spinning icon back over a stopped process — the exact failure this commit is fixing, arriving by a different route. It is the tray's now, so it survives the panel being closed. Still per-session: a reload forgets, and the button then offers Pause on a job that is already frozen. SIGSTOP makes that harmless, and the honest fix is asking the process rather than remembering — `ps -o state=` on the pids holding the output file would make it survive anything, at the cost of a spawn per poll. Worth doing if this ever misleads. The chip is unchanged: a paused job still shows the running dot there, because live is what that dot means and the distinction belongs where the controls are. tsgo clean, frontend builds, 914 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
c7749308e1 |
a path that climbs out of the proxy is collapsed before it is prefixed
The blank preview, and it was never the restarts. Bun's dev server emits
href="/../../../chunk-qmw09gd9.css"
Root-absolute AND climbing. Prefixed naively that is
`/api/dev-proxy/3001/../../../chunk-…`, which the BROWSER normalises straight back
to `/chunk-…` — the platform root, where it 404s. Two failed asset requests, a
white pane, and nothing in the network tab suggesting a proxy was involved. The
rewrite looked correct in isolation and was undone by whoever read it.
`..` is resolved by the consumer, so it has to be resolved before the prefix goes
on. Both halves do it now: `rewriteHtml` for what is written in the document, and
the injected script for URLs built at runtime, which Bun also emits in this shape.
Verified through the whole stack against the real app on 3001: document 200, both
assets 200 with `text/css` and `text/javascript` — where before they were 404s at
the platform root.
13 tests, and one of them asserts the failure rather than the fix: that
`/api/dev-proxy/3001/../../../chunk-x.css` really does resolve to `/chunk-x.css`.
Without that line the other tests look like arbitrary string manipulation.
── Separately, and not a bug in this code ──
Two processes were listening on 3001, holding DIFFERENT task output files
(`b0oe99a47` and `b6zat0x7e`) — two independent jobs, not one restarted. Bun allows
both to bind through SO_REUSEPORT, so requests were split between them and stopping
one legitimately left the other serving. That is worth knowing before reading a
Stop as broken, and it is the second time today SO_REUSEPORT has made a duplicate
invisible.
tsgo clean, frontend builds, 914 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
bda5eb15de |
a job's controls can no longer freeze the platform
The server went down. It had not: it was STOPPED — eleven threads in state T, port 9000 still listening with connections queueing behind a process that would never accept them. Indistinguishable from a crash unless you look, which is why it took a terminal to see. `kill -CONT` brought it back with nothing lost. I did it, with one missing line. `restartBackgroundTask` opened the job's output file to hand the child a descriptor and never closed it, so the PLATFORM became a holder of that file. `pidsHoldingFile` asks `fuser` who holds it — that is how Stop finds a job with no recorded pid — so the platform was in the answer. The next Pause sent SIGSTOP to it. Every part worked as designed. Pause froze exactly what was holding the file, and one of those things was the thing doing the freezing. Two fixes, and the second matters more than the first: **Close the descriptor.** The child gets its own duplicate at spawn, so closing costs it nothing. That removes this instance. **Never signal our own pids, whatever `fuser` says.** `pidsHoldingFile` now filters `process.pid` and `process.ppid`. The leak is fixed; this is what makes the next one survivable. Nothing that manages a job should be able to name the process doing the managing — a rule worth having independently of the bug that suggested it. Verified: after a restart this process holds the output file zero times, `fuser` returns only the spawned shell and its child, and our own pid is filtered even when present. tsgo clean, frontend builds, 901 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bc2bafe24a |
a queue can no longer be delivered to the wrong conversation
My fix was worse than the bug it replaced. Queue in one chat, switch to another,
and the messages were SENT there — into a conversation the person had not written
them in.
`ChatDetailPanel` mounts `<EmbeddableChat sessionId={undefined}>` and passed no
panel id, so `queueKey` fell through to `screen:new` for every conversation it
showed. One key, every chat. Switching restored the queue into the chat being
opened, and the mount-drain I added — which exists so a returning queue is not left
sitting there — then delivered it. Two of my changes, each defensible alone,
combining into the worst outcome available.
Three things, in order of what actually protects the user:
**A key that cannot be shared.** `queueKey` returns null when neither a panel nor a
session identifies the mount, and null persists nothing. Then an unidentifiable
chat behaves exactly as it did before any of this: queue local to the mount, lost on
a switch. That is the original complaint, and it is strictly better than delivering
to the wrong place. A shared key is worse than no key.
**The drain refuses a null key too.** Belt and braces: nothing was restored, so
nothing may be sent.
**`ChatDetailPanel` now says which conversation it is**, from `resumeSessionId`,
which it already had in scope. The identity was one line away the whole time.
Three tests pin it, including the collision itself: two resumed conversations must
not produce the same key, and a null key must never persist.
The lesson I would rather write down than repeat: I added the mount-drain reasoning
about a queue's promise, and never asked what it would do if the key were wrong. A
mechanism that sends messages needs its failure mode considered before its happy
path.
tsgo clean, frontend builds, 901 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
19e75651e7 |
a restart runs the job in its own directory, or not at all
Restarting a `bun dev` belonging to a project in ~/dockers/officer-atelier started the PLATFORM's dev server instead. The respawn passed no cwd, so it inherited the server's own working directory, where `bun dev` means something else entirely. The result was not an error. `bun --watch src/server.tsx` came up and bound port 9000 ALONGSIDE the running platform — Bun allows that through SO_REUSEPORT — so requests were split at random between two instances of the platform. Confirmed on the machine by ancestry: `sh -c bun dev` → `bun dev` → `bun --watch src/server.tsx`, with two listeners on 9000. Stray killed; the real server was unaffected. The information was there all along: every transcript entry carries `cwd`, and the entry holding the tool call is the one that says where it ran. `commandForTask` returns both now. And when there is no cwd it REFUSES, rather than falling back to the server's own. The fallback is what produced this, and it produced the worst outcome available — not a failure, but a different program running successfully. A command is only meaningful with the directory it was written for. Verified with a job whose transcript says it ran in /tmp/cwd-probe-app: the restart reports that directory and the respawned process prints it, reading a file that exists only there. tsgo clean, frontend builds, 898 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
0d3a7fc33f |
queued messages survive switching to another chat
First report from somebody who is not us. Queue messages in a chat that is working, open a different conversation, come back: gone. Not a bug in the sense of code doing the wrong thing — `ChatPanelInner` is keyed on the session id, so opening another conversation REMOUNTS it, and that key is load-bearing (`useChat` seeds its state from the first session id it sees, so a remount is the honest way to say "this is a different chat"). The queue was local state and died with the mount. It was built for the minute between writing a message and a turn ending; switching away mid-turn was never in that picture. Now it lives in a module-level store, seeded on mount and written through on every change. Losing text somebody typed is the worst thing this could do, and it was doing it silently. ── Keyed by panel AND session ── Two panels can both be on a new chat, where the session id is `new` for both. Keying on the session alone would hand one panel's queue to the other — the same class of mistake wearing the opposite face. ── One decision that was not in the report ── A restored queue now DELIVERS on return if the agent is free. The existing drain only fires when a turn ends, and a remount has no such transition to watch, so without this you would come back to your messages sitting in the tray with nothing about to happen — which is the second report I would get. "These go when the agent is free" is the promise; the agent being free is exactly that case. Only on mount, and only when nothing is running: while a turn IS running the ordinary drain owns them, and firing here too would deliver twice. ── Not persisted, deliberately ── Module state, so it dies with the tab. A queue is a promise about the next minute; restoring one on a page loaded tomorrow would fire a message into a conversation whose context has moved on. Surviving a panel switch is the whole requirement. 11 tests, including the two-panels-on-one-conversation and both-on-a-new-chat collisions. tsgo clean, frontend builds, 898 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
d9bffe5471 |
the dev proxy was mounted behind the auth middleware
"Unauthorized" in the pane, and that word is the whole diagnosis: this router's own refusal says "Not authorised for the dev proxy. Open it from the Preview panel." The text on screen came from `userMiddleware`, which means the request was rejected before the router ever saw it. I had mounted `/dev-proxy` in the PROTECTED table. Everything there gets `userMiddleware`, which requires an Authorization header — and an iframe navigation is a navigation, not a fetch, so it has none. The document 401'd every time. The cookie work in the last commit was correct and could never have helped: nothing was reaching the code that reads the cookie. Moved to the unprotected mounts, beside `/auth` and `/sidecar`, with the reason written where the list is. It is not open — the router verifies the OWNER's token on `/session` and requires the cookie it issues on everything else. ── Why I did not catch this myself ── My tests mounted `devProxyRouter` on a bare Hono app. That proves the router and nothing else, and the bug was entirely in what sits in front of it. Retested through `buildHonoApp()` — the real assembly, every middleware — where `/session` returns 200 with a cookie, the frame returns 200 carrying the dev server's own HTML and injected script, and an uncredentialled request now gets THIS router's message rather than the middleware's, which is the observable difference that proves the path. A test that constructs its own subset of the system will keep passing while the system is broken. Worth remembering the next time a router is proven in isolation. tsgo clean, frontend builds, 889 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
fccabfcea3 |
the preview authorises itself before it mounts the frame
401 on every asset, white pane. The server was never wrong — replaying the exact browser sequence with a minted owner token gave HTML 200, `set-cookie` present, and the sub-resource authorised. So the fault was in how the frame got its credential, and both mechanisms it relied on were guesses. Putting the token on the iframe URL guesses which key the browser stored it under. Letting the frame mount and hoping guesses that a cookie from some earlier load is still there. When either guess misses, the HTML renders, every sub-resource 401s, and the pane is white — which is the shape that makes this hard to read, because the document loading looks like success. So neither is used now. The panel asks `/api/dev-proxy/session` with the ordinary API client — which already knows how to authenticate, because it sends the header on every other call it makes — and mounts the frame only once that returns. The iframe URL carries nothing. `iframeSrc` is deleted rather than left as a fallback: a second path that runs when the first fails is how you get a bug that only appears sometimes. `Authorization` rather than a query parameter, so the token never reaches an address, a log or a Referer. Re-run on every reload, so a preview left open overnight recovers by itself instead of showing a wall of 401s. ── Also fixed: a lie attached to every binary asset ── The non-rewritable branch returned the upstream's `content-encoding` and `content-length` unchanged, but `fetch` had already decompressed the body — so the browser was told to inflate plain bytes, with a length that no longer matched. The rewrite branch had always deleted both. Images, fonts and wasm were affected; nothing had hit it yet because the test app serves none. Verified: `/session` 200 and sets the cookie with a token, 401 without; the frame 200 with the cookie, 401 with nothing. `[open]` A request that escapes the prefix hits the SPA catch-all and returns `200 text/html` instead of 404, so a `<script>` gets HTML, the MIME check refuses it silently, and nothing appears as an error. That masks this entire class of bug and is worth closing separately. tsgo clean, frontend builds, 890 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
73eb128fb1 |
pause, resume and restart a background job without asking the agent
Three buttons in the expanded task panel, beside Stop. Not on the chip: the panel is where you decide what to do with a job, and a row of unlabelled glyphs on a pill is where you misclick. ── Pause / Resume ── SIGSTOP and SIGCONT — the only pair that means "stop doing things and keep everything". The process keeps its memory, its open files and its bound port, and picks up mid-instruction. Signals go to every pid holding the job's output file, because for a shell job that is the shell AND what it spawned, and freezing one of them would be worse than freezing neither. Verified by watching a job that writes a line a second: 3 lines, frozen at 3 across three seconds of pause, 6 after resume. Worth knowing before pressing it: a paused server does not REFUSE connections, it stops answering them, so a browser pointed at it hangs rather than erroring. That is what pausing is, not a shortcoming here. ── Restart, and the cost it accepts ── The command is recovered by joining the transcript to itself: the harness records the `tool_use` carrying `command`, and separately its result — the text `Command running in background with ID: <id>`. Neither alone is enough; together they are a join on `tool_use_id`, and that is the only place the command survives. The transcript is found FROM the output path rather than searched for, since a task file at `<tmp>/claude-<uid>/<slug>/<session>/tasks/<id>.output` names both. The respawned process appends to that same output file. That is what keeps everything else working untouched — the log view reads that file, and Stop finds the process by asking which pids hold it open. The real cost, chosen deliberately: the platform becomes a SECOND owner of a task. The harness stops watching when its own child dies, so the platform supervises what it spawned and emits the same `task:started` / `task:notification` pair everything downstream is built on. `emitToSession` is the seam, and it is the only one — nothing else learns that a task can have two kinds of parent. A restart re-announces an id already in the transcript, so `task:started` now RESETS an existing task row rather than appending a second one. Without that the tray showed the job twice, once finished and once running. Restart is offered for a finished job too, which is the case that matters most: a dev server that fell over is exactly what you want back without typing a sentence at an agent that may be mid-turn. Verified end to end against a planted task: command recovered, old process killed, new one spawned, output APPENDED (`first run output` then `RESTARTED-OK`), exit reported through the callback, supervision registry released afterwards. `[open]` A restarted job does not survive an `officer` restart — the platform is its parent now. The harness's own jobs never did either. tsgo clean, frontend builds, 890 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7d64b0a0d6 |
paste localhost:3000 into the preview and see the server's port
No proxy host, no certificate, no port opened. `/api/dev-proxy/5173/…` forwards to `http://127.0.0.1:5173/…` over the platform's own origin, and the panel maps what you type onto it. ── Why a proxy at all, when the ask was "just point at localhost" ── Neither direct route works from a browser on https://<platform>. `http://localhost:5173` resolves on the VIEWER's machine, not the server's, and `http://<server>:5173` is mixed content inside an https page and is blocked before it is even attempted. Both fail looking exactly like the dev server being down. The bytes have to arrive over an origin the page already trusts, which is the platform. A dev server can therefore stay bound to 127.0.0.1. The workflow this replaces — one NPM proxy host per app — needs it on 0.0.0.0 plus a firewall rule for the docker bridge, so this is both less setup and less exposure. ── What came back from `188b45c1^`, and what did not ── The 46-line HTML/asset rewrite, which is the hard-won part: absolute paths in the document, plus an injected script that intercepts fetch/XHR/WebSocket for the URLs built at runtime. Its JWT injection is deleted — those apps called the PLATFORM's API; a dev server proxied here talks to itself, and handing its process the owner's bearer token would be giving credentials to whatever is on that port. The other 314 lines are not back: spawning, port discovery, idle timers, log collection, a proxyId registry. The port is the id, and the background-job button already starts dev servers. ── HMR is bridged, because "see it" without "follow it" is half the feature ── The injected script rewrites the dev server's socket under the prefix; the relay dials `ws://127.0.0.1:<port>` and forwards frames both ways. Same shape as the vault relay including the non-obvious part — state registered synchronously and frames queued until the upstream opens, because Bun requires the upgrade to be synchronous and an HMR client speaks immediately. An upstream close closes the client, which is what makes a dev-server restart reconnect by itself. ── Access, which was not in the ask and is not optional ── This route reaches any loopback port on the machine, on a host that answers from the public internet. An iframe cannot carry a bearer token — it is a navigation — so the panel puts it in the URL once, the proxy verifies it is the OWNER through `resolveAuthToken`, and issues a short-lived cookie every sub-resource then carries. Anonymous and non-owner requests get 401, verified. Owner-only rather than a permission: reading an arbitrary loopback port is the `execution` power the registry says can never be granted. Both exemptions are registered with reasons, and the boot check earned its keep — it refused to start until the socket provider was claimed too. ── Verified against a real loopback-only server ── Confirmed unreachable from outside, then through the proxy: index served and rewritten, `/_bun/` chunk resolved, JSON passed through untouched, 401 anonymous, 401 with a bad token, "nothing is listening" on a dead port. Websocket: refused without the cookie, target parsed, frames relayed in both directions. One bug found by testing rather than reading: the upstream path was derived by slicing a hardcoded prefix, so every asset request returned the index page. It is found from the `/<port>` segment now. A test asserting `http://localhost:5173` is kept verbatim is now inverted, with the reason written beside it — that was correct when the panel only framed real hostnames. tsgo clean, frontend builds, 890 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
83cd7af156 |
a kickoff prompt for the next extraction, and a runbook that is true again
`plugins/EXTRACT-A-PLUGIN-PROMPT.md` is meant to be pasted into a fresh agent with one word changed. It deliberately does not restate the runbook — it orders the reading, says what "done" means, and sets the three behaviours that matter: map the import graph before moving anything, ask rather than assume, and verify on a live server after a purge. ── The runbook needed correcting before it could be handed to anyone ── Its verification table told the reader to run `bun db:push` while the plugin was uninstalled and expect "No changes detected". Following that today would hang on drizzle-kit's interactive rename prompt, or — with `--force` — drop the tables of every plugin not currently on disk. Struck out, with the reasoning, and the property it was checking is now checked by reinstalling and finding the rows still there. Also folded in: installs create tables through `pushPluginSchema` and verify them afterwards; `purge` is the only honest way to test an install twice, because uninstall keeps the directory and the tables on purpose; orphan tables are now reported on screen; and the marketplace is part of the job — a public repo that clones anonymously, a README that renders in both the store and the install pane, a catalogue row, and a `BUNDLED` entry for machines with no internet. Two rules from today that generalise beyond extraction: the platform must not carry the plugin's VOCABULARY, not just its code — ten comments explained what Headscale was months after it left, each correct and in the wrong repository — and nothing in the install path may trust `$PATH`, which cost an install with `Executable not found in $PATH: "bunx"`. The stale "757 pass, 10 failures" is now "record the baseline before you start", which does not go out of date. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
74f2e59069 |
the tray stops filling with the agent's own commands
"So the pills don't get polluted with those calls that you're making." First, a correction to what I assumed. The platform is not mis-detecting anything: the SDK emits `task_started` only for real background work, and I checked — a foreground `echo` produces no task event at all. What produces these is the HARNESS auto-backgrounding a foreground command that runs long. Measured against the installed SDK: a 24-second foreground Bash call emits `task_started` with `task_type: 'local_bash'`, identical in shape to one started with `run_in_background: true`. There is no field that separates them, and there should not be — by then they are the same thing. So the chips were real. They were just not anybody's business: a tray of green ticks for greps and typechecks, sitting beside the one job that was started on purpose. The rule is now about ORIGIN rather than state, using the arm-and-claim that already exists for the preview: running shown, whoever started it — it is live and it can be stopped finished, yours kept (up to five), because you asked for it and the outcome is the point finished, the agent's dropped the moment it ends pinned kept regardless Running jobs stay visible deliberately, including mine. A background command of the agent's that has gone wrong is exactly the thing worth seeing and stopping, and the stop button already adopts anything you press it on. Extracted as `visibleTasks`, pure and tested — six cases including the cap, the pin override, and running-before-finished surviving the new filter. `[open]` Origin is process state, so a reload forgets it and a previously-yours finished chip is then treated as the agent's and dropped. Acceptable — after a reload you are not watching that completion — and making it survive means putting origin in the transcript, which is a wire change. tsgo clean, frontend builds, 884 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7fdb09af0a |
speaking mid-turn no longer declares the turn over
Reported as "the output I see with turn complete is very very misleading", and it
was: the transcript printed "Turn finished · no closing message" between a tool
call and an injected message, while the header two inches away still said Working
and a task chip still said 1 RUNNING. The UI stated the opposite of what was
happening.
`turn-rows` treats every user message as a turn boundary. That was right when the
only way to speak was to wait. Delivering a queued message INTO a running turn made
it wrong: the boundary split the live turn, the half before it therefore counted as
`complete`, and having tool calls and no answer it matched exactly the rule that
prints a silent ending. The seam meant for a rare confusing case fired on an
ordinary one, and said something false.
So a user message now carries `injected` when it was sent while a turn was already
running, and only a message that STARTS a turn is a boundary. Read from
`isGeneratingRef` at send time rather than from state — `sendPrompt` is called
from closures built a render earlier, and the question is "was a turn running when
this was sent", which is what the ref holds.
Five tests, including the contrast case: the same messages WITHOUT the flag still
produce the boundary and the ending, because a genuine second turn should end the
first. A turn that really did finish silently still says so — that seam was worth
having and is not what was broken.
Verified live on the way in: the injection reached this session mid-turn, attached
to a tool result, and changed what the turn did.
Still outstanding from the same screenshot, not touched here: foreground Bash calls
render as background tasks ("Running in the background…", and a chip in the tray).
That is a separate misreport.
tsgo clean, frontend builds, 878 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
0230e62a71 |
the platform stops explaining what Headscale is
Correcting my own reasoning from the last commit. I left "Headscale's API", "the Headscale admin credential" and similar alone on the grounds that they name the thing the plugin drives, so renaming them would make the sentences false. True as far as it goes, and it misses the point: those sentences are in the PLATFORM. It has no business knowing what Headscale is at all. Correct language in the wrong repository is still a remnant. Ten of them, each replaced with the platform's own vocabulary rather than the plugin's domain: - `crypto.ts` and `secret-store.ts` listed "the Headscale admin credential" among what one key used to protect. It is "the tailnet's admin credential" — the purpose, which is a word this repository owns. - `catalogue.ts` and `availability.ts` explained `alsoServes` — a LIVE mechanism — entirely through a Headscale example that left the repository. Restated as the general shape, with one parenthesis saying which case produced it. - The photos types file explained another plugin's sidecar. - `App.tsx` cited `/headscale/:section` as the example of a route pair; that route does not exist. `/photos/:section` does. - `plugins/router.ts` pointed at `useCompanionLogStream`, a hook that lives in a plugin now. - `registry.ts` said in the present tense that `headscale` is `admin` — the permission is the plugin's and it declares its own, so a member-facing enrolment surface would be the PLUGIN's to add, not this file's. - `proxy.sh` cited `headscale/schema.ts` as a style reference. That file is not in this repository. - machine-setup said "Its Headscale app" — the app is the Offscale plugin. `machine-setup/lib/tailscale.sh` keeps all ten of its mentions: it exists to explain tailscale, headscale and offscale to somebody choosing between them, on a core install, before any plugin exists. That is machine setup's subject, not the plugin's domain leaking upward. What survives elsewhere is only dated history — "was here until 2026-08-15", "It was: music, vault, slskd, headscale, …" — plus the notes about the real `headscale_servers` orphan and the secret-store key removed yesterday. Those record that something called headscale used to be here, which is a different claim from explaining what it does. tsgo clean, frontend builds, 873 pass / 7 fail unchanged, setup scripts parse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
27aa72d923 |
finish the offscale sweep: two real remnants and eleven stale names
Asked for a thorough check that nothing of offscale is left in the platform. The extraction was sound — no router, no permission entry, no app-store entry, no screen, no panel app, no env var anything reads. Two things were genuinely wrong, and both were in setup rather than in the server. ── The secret store minted a key for a plugin ── `officer-setup` bootstrapped two purposes: `jwt` and `headscale`. The second was a key for a PLUGIN, under a name the rename had already replaced, on a machine where the plugin is not installed and nothing would ever ask for it. offscale encrypts under `offscale`, and `getKey` creates on demand — which is precisely what lets core know nothing about plugins. Now core bootstraps `jwt` alone. ── `.env.example` documented variables for a deleted router ── HEADSCALE_URL, HEADSCALE_API_KEY and HEADSCALE_USER were described as driving `/api/vpn`. That router was deleted on 2026-08-14 and nothing has read any of them since. Left as a note saying where the tailnet's credentials live now, because somebody with an older `.env` will otherwise wonder why setting them does nothing. ── Names that outlived the thing ── Eleven comments referred to the plugin's route, panels, console or server registry as "headscale": three sidecar config files describing their own shape by pointing at it, two screens citing `/headscale` as the example of a Workspace/Panel route, the terminal's note about the Console, and the photos types. Also `catalogue.ts`, which still claimed headscale "is CORE now", and `working-on-officer.md`, which told the reader a core install runs six processes including `officer-headscale`. Upstream references are deliberately untouched: "Headscale's API", "the Headscale admin credential", "is this a Headscale server?" all name the thing the plugin drives, and renaming those would make the sentences false. `docs/secret-store.md` argued headscale must be core because the tailnet is the perimeter. Marked superseded rather than deleted, with the distinction that settles it: the perimeter is the tailnet EXISTING, which machine-setup still arranges on a core install — not the platform shipping the screen that administers it. Verified by counting: live code, setup provisioning, env references, permission entries, app-store entries, hono mounts, dock defaults, screens and panel apps all zero. What is left is generated files (Plugins.gen, plugin-schemas.gen), the bundled catalogue entry, test fixtures using "offscale" as an example app name, and history. tsgo clean, frontend builds, 873 pass / 7 fail unchanged, setup scripts parse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
c0e61a4cba |
the trap keeps its evidence, and says where the procedure is
This bug will not be reproduced on demand. It will arrive as somebody's report, hours later, from a browser whose console is long gone — so a `console.warn` is seen by nobody, and "what did you see?" gets an answer built from memory and a screenshot. So the trap now persists. Up to five occurrences in `localStorage['officer:editor-buffer-trap']`, each carrying the stack at the moment of the edit, the first 200 characters that arrived, how many, which file, and when. The question becomes "paste this key", and the answer is complete. Recording a bug must never become one: private mode, a full quota and a disabled storage API all throw at that write, and none of them is worth breaking an edit over. The console line survives either way. `docs/editor-buffer-corruption.md` is the procedure — what it looks like, the four candidates already eliminated and why, the one command to ask a reporter for, how to read each field, what an EMPTY key would mean (either the editor was focused, making it a paste, or the insertion came in chunks under the threshold), and the instruction to delete every piece of this once the cause is known. Linked from TODO.md and from CLAUDE.md's reading list, so somebody handed a report finds it without grepping for it. Stated there rather than left implicit: a fix invented without knowing the cause would hide the symptom on the one screen where it is visible while the mechanism carried on doing whatever else it does. The corruption is never saved and reopening the tab clears it, so waiting is cheap and a wrong fix is not. tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
fc8d02e8e1 |
set a trap for the editor buffer corruption
Not a fix — I could not find the cause by reading, and shipping a guess dressed as
one is worse than saying so.
What reading DID settle, and it removes two of the three candidates:
- The end-of-turn refresh cannot be it. `reloadFile` sets `originalContent` and
clears `isDirty`, so no refresh can produce the dirty dot in the screenshot.
- Nothing in the app types into the page: no `execCommand('insertText')`, no
synthetic keyboard events, no clipboard writes anywhere near the editor.
That leaves Monaco's own change event, which means the model was edited the way a
paste or a programmatic `executeEdits` edits it. Neither is identifiable from a
screenshot taken afterwards, which is why this needs to be caught in the act.
`reportSuspiciousEdit` logs any insertion over 200 characters arriving while the
editor does NOT have focus, with an Error constructed at that moment so the stack
names the caller. A person cannot type 200 characters into an editor they are not
focused on; whatever does will be in that trace.
It prevents nothing and changes no behaviour. Delete it once the cause is known.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
23f2ecb950 |
todo: the marketplace's deferred work, ranked
Split out of docs/marketplace.md so the design document stays about how it works. Ranked by what blocks something rather than by size: submissions first (until a stranger's manifest can be read without executing it, the catalogue is ours only and everything below is cosmetic), then plugin upgrades not migrating, then staleness, then scale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
dc420ba5a2 |
stop assuming bunx is on the service's PATH
`Executable not found in $PATH: "bunx"` — installing music died there, after the
clone and after apt had installed ffmpeg. My bug, one commit old: the schema step
spawned `bunx drizzle-kit`.
PM2 starts the platform with a PATH that has `bun` and not `bunx`. That is a
perfectly normal way for a service to be started — a symlink into /usr/local/bin
for the runtime and nothing else — and an install has no business depending on
which of a runtime's shims someone happened to link.
So neither name is looked up now. `process.execPath` is the interpreter already
running this code, so it cannot be missing, and drizzle-kit is invoked by path
through `node_modules/.bin/drizzle-kit` rather than by resolution. A missing CLI
there is reported as "run bun install" instead of as a PATH mystery.
Verified the way the claim demands: re-ran the schema push under
`env -i PATH=/usr/bin:/bin`, where `Bun.which('bunx')` and `Bun.which('bun')` both
return nothing. It works. The previous run proved nothing, because bunx was still
there.
Worth noting for the next spawn added to this path: `git`, `pm2` and `sudo` are
still PATH lookups, and they are the ones that were already working on the
machines we have. Anything new should follow this pattern instead.
tsgo clean, frontend builds, 873 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
e0d3f59b9b |
name the tables nothing on this machine owns
The marketplace screen now lists tables in the database that no code here claims, with a row estimate and, where the prefix says so, which absent plugin they look like they belong to. This is the information that cost an evening. `bun db:push` saw tables the schema did not declare, asked an interactive question no non-TTY caller could answer, applied nothing and exited 0 — and the install reported success while the plugin was unusable. The cause was two tables from before an extraction, found by reading `\dt` by hand. Nothing in the platform would ever have mentioned them. ── What counts as an owner ── The core schema, or a plugin DIRECTORY — not a plugin INSTALL. A plugin that is present but uninstalled still owns its tables, because that is the promise uninstall makes: keep every row so a reinstall puts you back where you were. So this reports only what no code on this machine describes at all, which on a healthy install is nothing, and the block does not render. A plugin whose schema will not import has its prefix treated as claimed rather than having every one of its tables reported as unowned — a broken manifest should not read as data with no home. ── No delete button, deliberately ── Dropping a table is not something to offer beside a list of plugins, and the right action differs per row: `music_favorites` wants the music plugin installed, `headscale_servers` wants dropping. Naming them is the part that was missing. Verified by planting `headscale_servers` and `music_playlists_old` and reading them back through the same call the route makes: the first attributed to nothing, the second to music, which is not on this machine. Row counts come from `pg_class.reltuples` — an exact count on a large table is not worth blocking a page render for a number that only answers "is there anything in here". tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8d8fbe2903 |
delete the global push from the server, keep the warning
`pushSchema()` had no callers left once installs stopped using it, and it is not the kind of dead code worth keeping around: it is a one-line way to run the exact command that stopped applying anything on a real server, and dropped tables when forced. The doc comment stays in its place, because the useful artefact is the reason rather than the function. `bun db:push` remains correct in exactly one situation — `officer-setup`'s build step, on a machine with no tables yet, where "make the database match this schema" is an instruction with no ambiguity to resolve. Every other caller now has a scoped path. tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
221e370442 |
a plugin install creates its own tables and cannot touch anything else
The logs from the last commit showed what was actually wrong, and it was worse
than a failed push.
── What the install was doing ──
`bun db:push` hands drizzle-kit the whole schema and the whole database and asks
it to make them match. On a machine holding tables the current schema does not
declare — a plugin that is not on disk, anything left from before an extraction —
it sees a new table appearing while others are due to be dropped, and asks:
Is offscale_servers table created or renamed from another table?
❯ + offscale_servers create table
~ headscale_servers › offscale_servers rename table
~ music_favorites › offscale_servers rename table
That prompt needs a TTY. `--force` does not answer it, `< /dev/null` does not
answer it, and piping newlines does not either — measured: it hangs until killed.
Without a terminal the push applies NOTHING and exits 0, which is exactly how an
install reported success on a machine where its table was never created.
And `--force` would have been the wrong fix. Force means "run the destructive
statements without asking", and the destructive statements there are `drop table`
for every plugin whose directory is absent. Installing one plugin could delete
another's data.
── `tablesFilter` was tried, and is not enough ──
Scoping the push to the plugin's tables stops it dropping other tables and it
still diffs sequences. Measured on a scratch database: installing offscale issued
`drop sequence passkey_challenges_id_seq` — a CORE platform sequence — because the
plugin's schema does not declare it. Postgres refused only because a column
default depended on it. A sequence without dependents would have gone.
── So: generate the SQL, then apply it ──
`drizzle-kit generate` against the plugin's schema alone, into an empty directory,
emits exactly the statements that build that schema from nothing. It diffs against
the migration journal — empty — not against the database, so it cannot emit a DROP
of anything, of any object type. There is no destructive statement to guard.
Applying is idempotent by exception: an object that exists raises 42P07/42710 and
is skipped, which is the normal case for a reinstall, since uninstall keeps data
on purpose.
`[open]` This creates; it does not migrate. A plugin version that adds a column
will not get it. Plugin upgrades need real migrations — a separate feature. The
old push appeared to handle that case, at the price of being able to drop half the
database.
── Verified ──
Fresh install: 4 statements applied, table verified, 761ms. Reinstall over
surviving tables: 0 applied, 4 already present. Core sequences before and after:
18. Orphan tables on a scratch database shaped like the failing server
(headscale_servers, music_favorites): untouched.
The reinstall case failed on the first attempt — drizzle wraps driver errors, so
the SQLSTATE saying "duplicate table" is on `cause`, and checking only the top
level made every second install fail on its own CREATE TABLE. Found by testing the
second install rather than stopping at the first.
tsgo clean, frontend builds, 873 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
c98b5643aa |
show what the commands are actually saying
Install, uninstall and purge narrated what the platform was doing and hid what it was running. Every spawn captured stdout and stderr, held them, and surfaced the last 600 characters only if the exit code was non-zero. That is enough to explain a crash and useless for the two things people want while watching an install: knowing a slow step is still moving, and seeing the warning a command prints on its way to exiting 0. The second is not hypothetical — `db:push` reported success on a machine where it created no tables. Its output was captured, discarded because the exit code was fine, and the failure surfaced minutes later as 42P01 in a sidecar log. Whatever drizzle said about that push, nobody ever read it. `runLogged` streams both pipes as they arrive, so they interleave the way they do in a terminal. Following only stdout would have been silent for exactly the commands worth watching: git writes everything to stderr, drizzle-kit writes progress there and results to stdout. Two pieces of noise control, because a log nobody can read is not an improvement: `git clone` gets `--progress` instead of `--quiet` (git says nothing when it thinks it has no terminal, and that is the step where a slow link looks like a hang) with per-percent rewrites collapsed to the last fragment per chunk; and drizzle's spinner, which is eight lines saying the same thing with a different braille glyph, collapses to the first — otherwise "Changes applied" scrolls past underneath it. Steps and output share ONE ordered list rather than two. Their order relative to each other is the whole information: "which step was this output from" is the only question the log exists to answer. Output renders dimmer and indented under the step that produced it. Verified by running a real purge and reinstall: the clone's object counts, the barrel generation naming both plugins, drizzle's push, then "schema: applied in 2029ms (1 table verified)". tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
3c03e61c5e |
delete a plugin and everything it owns, and stop trusting exit codes
Two halves of the same problem: a plugin installed onto a fresh machine, reported success at every step, mounted, started its sidecar, registered — and then failed its first query with 42P01, because `offscale_servers` had never been created. Nothing said so, and there was no way back to a clean machine to try again. ── The install now asks Postgres ── `pushSchema` only checked the exit code, and `db:push` is a compound command: generate the barrel, cd, run drizzle-kit. It can exit 0 having created nothing. So the install now reads the plugin's schema for the tables it declares and verifies they exist, failing the install with a message naming what is missing instead of leaving a stack trace to appear in a sidecar log minutes later. Tables that are NOT prefixed with the app name are reported as a warning rather than a failure — they still get created, but `purge` will not remove them and a reinstall would find them already there. ── `purge`, next to an uninstall that deliberately keeps everything ── Uninstall is careful on purpose: every table and row survives so a reinstall puts you back where you were. That is what makes it safe to try, and it left no way to get to a CLEAN machine. A second install finds the directory (so the catalogue hides the plugin) and the tables (so push has nothing to do, and a broken schema stays broken). So a different verb, a different word, its own confirmation. It reads the table list from the schema BEFORE deleting the source, uninstalls (stopping the sidecar — nothing may be running against tables about to vanish), drops, deletes the directory, then regenerates the barrel unconditionally, since a barrel naming a directory that no longer exists is what stopped a server booting yesterday. The table list comes from the plugin's own schema, not from `like '<app>_%'` — that query eventually drops somebody else's table, because the prefix is a convention nothing validates and `music` is a prefix of `music-videos`. The prefix is used as a GUARD instead: a schema module could export `users`, and anything outside the plugin's own namespace is refused rather than dropped. ── Verified as a full loop on this machine ── purge offscale → table dropped, directory deleted, barrel regenerated → the marketplace offers it again → install → cloned, ssh checked, "schema: applied in 2072ms (1 table verified)", dock pinned, mounted, sidecar started. I left offscale INSTALLED here rather than restoring the half-state it was in (no install row, table present, sidecar running). tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8ad5a5563e |
clicking a plugin works again, and offscale gets its icon
Two regressions and one long-standing hole, all found by actually opening the page. ── Clicking a row did nothing. That one is mine ── Rows link to `?selected=<app>`, and they still pointed at `/plugins`. My redirect was `<Navigate to="/marketplace" replace />`, which DROPS the query string — so a click went to `/plugins?selected=music`, redirected to a bare `/marketplace`, and the detail pane sat on "Select a plugin." Both halves worked; the redirect threw away what the link had just set. Rows now point at `/marketplace` directly. The redirect also preserves `search`, because old bookmarks carry the same param and losing it is exactly what made this wrong the first time. ── Offscale's icon 404'd since it shipped one ── Assets were published to `public/plugins/<app>/` at INSTALL and nowhere else. Offscale was installed before it had an `assets/icon.png`, so the directory never existed and the tile drew a 404 permanently — nothing short of uninstalling and reinstalling would have fixed it. "Reinstall the plugin to see its new icon" is the same bad answer as "restart the server to see it", which the route right next to this already refuses to accept. Publishing now happens on every mount. It is a copy of files that still exist in the plugin's own source, so re-running it is free and cannot lose anything — the property that already makes unpublish the one thing uninstall may delete. A failure is logged, never thrown: an icon is not worth refusing to mount over. Published offscale's by hand too, so the fix is visible without waiting for a restart. Verified 200 through the running server for both plugins. ── The third report was not a bug ── "No connection to the marketplace" is the catalogue working correctly: all three plugins are already on disk here, and `router.ts` drops catalogue entries whose plugin is installed, because offering to install something installed is worse than showing nothing. With nothing left to offer, a working store and a broken one look identical on that screen. Nothing in the logs, which is what a reachable store looks like — the client only speaks when it cannot reach one. tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bfb20b6916 |
the /offscale route comment, and the store learns about ssh
The platform's own reference to offscale was one stale comment naming /headscale as an example route pair. Everything else that matches "offscale" in src/ is a test fixture using it as an example app name, or the bundled catalogue entry. Re-synced the marketplace so the catalogue advertises the ssh dependency the manifest now declares — which is the point of the sync being cheap to re-run: a plugin's manifest changing is not a marketplace deployment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
ba20155a09 |
the store's README shows in the platform, not just on the website
A plugin's page in the Marketplace screen now renders the README the marketplace holds — the same text the public site shows, in the pane where somebody actually decides whether to install it. Fetched by the SERVER and proxied, though CORS would have allowed the browser to ask directly. An Officer client is routinely somewhere its server is not: a phone on the tailnet, a laptop with the store blocked. The server already had to reach the marketplace for the catalogue, so routing through it means the README appears in exactly the cases the plugin list did — rather than in a strictly smaller set, which is the kind of difference nobody reports and everybody notices. Separate request from the list, because the list endpoint deliberately carries no READMEs: three of them is ~38KB of markdown on the request that draws the tiles. This one fires when a plugin is opened. Absence renders nothing at all — no error, no empty state. A plugin without a README is normal and a store that is down must not put a failure message on a page whose job is installing things. Under `/plugins` so the existing permission covers it: reading the store and installing from it are the same privilege, and a second key would be a second thing to grant for no separate decision. tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
53742a256f |
marketplace.officer.dev is live, and the plugin repos have READMEs
The site is up on HTTPS with a Let's Encrypt certificate, proxied to :9100, and serving the three plugins out of `officer_marketplace`. An Officer install with no configuration now reads its catalogue from it. ── What is running ── PM2 entry added to THIS machine's ecosystem only. Deliberately not in officer-setup's CORE_PROCESSES: the marketplace is one website officer.dev hosts, not something every install should run — a copy on every machine would serve a stale catalogue on a port nobody asked to open. nginx (NPM host id 7) → 172.20.0.1:9100, with a ufw rule for the docker bridge. That rule is not optional and its absence does not look like a firewall problem: without it nginx HANGS until proxy_connect_timeout rather than being refused, which is how the apptest hosts wasted an hour a few days ago. ── READMEs ── `music`, `offscale` and `example` now have proper READMEs, written against their own code and pushed to their own repos. They render on the plugin's page in the store and are what a self-hoster reads before installing. The example's is a tutorial as much as a shop window — it is the document a plugin author reads first, and every convention in it was verified in `discover.ts` rather than restated from memory. `music`'s remote was HTTPS with no credentials on this box, so it could not be pushed; switched to SSH like the other two. The catalogue still advertises HTTPS — `marketplace-sync` converts — which is the property that matters, since an `ssh://` clone URL only works on the machine that published it. ── Writing them was the cheapest audit available ── Reading each plugin against its own documentation turned up ~20 real defects, all recorded in TODO.md and none fixed here. The pattern worth naming: offscale is still branded "headscale" in user-visible panel names and in a persisted terminal session id, and its PLUGIN.md states outright that the ACL assistant is deliberately unwired — while `sidecar/assist.ts`, `claude-proxy.ts` and `PolicyAssistant.tsx` all ship. Documentation that confidently describes the opposite of the code is worse than none. Also fixed the docs on the frozen lockfile: both CLAUDE.md and bunfig.toml named `bun install --no-frozen-lockfile` as the escape hatch, and bun 1.3.14 has no such flag — it is ignored and the install fails anyway. tsgo clean, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
1b65b83f1f |
the plugins screen becomes /marketplace
`/plugins` redirects rather than 404s: the word is in the dock, in the docs and in whatever anyone bookmarked, and a route that worked yesterday returning nothing reads as the feature having been removed. The API keeps its name — only the screen moved — so the permission entry lists both paths, because a client-side redirect is still a route that has to resolve before it can send anyone anywhere. Also: the fetch stubs in marketplace.test.ts needed `as unknown as typeof fetch`. Bun's `typeof fetch` carries `preconnect`, so a bare stub is not assignable — tests passed while tsgo did not, which is the wrong way round to find out. tsgo clean, frontend builds, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
921fbff9fe |
marketplace.officer.dev: the catalogue becomes a service
The plugins page read a TypeScript constant. It now reads a public API backed by its own database, and falls back to that constant when it cannot. ── Four pieces ── `src/databases/marketplace_db` — a second Postgres database, `officer_marketplace`. Two tables, split by owner and lifetime: `plugins` is the registry (app name, developer, clone URL) and is authoritative; `plugin_metadata` is a CACHE of what each repository says about itself, so the website can render without cloning three repos per page load. Keeping them apart is what makes the cache safe to be wrong — a refresh can never lose the fact that a plugin exists. `scripts/marketplace-sync.ts` — fills it from the plugin repositories. Reads each `manifest.ts` (imported, since a manifest is TypeScript), derives `has` from the directory rather than trusting a declaration, and rewrites SSH remotes to HTTPS: `example` and `offscale` had `git@gitea…` origins, which would have handed every installer a URL that only works on the machine that published it. `src/servers/marketplace/server.tsx` — its own process, its own port, two GET routes and no others. Not part of the platform server: it has no users, no sessions and no request it answers differently per caller, and mounting a public unauthenticated surface inside the process holding mail, a wallet and passkeys means writing permission-gate exemptions that later turn out to be too wide. `src/apps/marketplace` — the public site. A window, deliberately: nothing here installs anything, because installing means cloning a repo and starting a process on someone else's machine. Every plugin page ends at "install it from your own Officer". ── The platform side is the part that had to be careful ── `fetchCatalogue()` now answers live → cached → bundled, in that order, and never throws. The plugins page is where an owner manages plugins they ALREADY have, so the store being down must not take that page with it. Network responses are validated per entry — not against a hostile marketplace, which has already won if the owner installs what it lists, but against a wrong one: a proxy serving HTML, a half-deployed API, a field renamed on one side. A non-https `source` is refused outright because that string reaches `git clone`. 8 tests on the degradation path. Verified end to end against the running service: live catalogue, cached answer surviving the store dying, bundled fallback. ── One thing found on the way ── `bunfig.toml` and CLAUDE.md both document `bun install --no-frozen-lockfile` as the way to change a dependency. Bun 1.3.14 has no such flag — only `--frozen-lockfile` — so the documented escape hatch does not work. Sidestepped by not making marketplace_db a workspace member (relative imports, zero lockfile change), and `bun install` is frozen-clean again. Worth fixing the docs. tsgo clean, 873 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8c66042e42 |
todo: background job logs appeared inside an open file in the editor
Reported on the production host, as a member, with a `bun dev` job streaming: the runner's output rendered into the buffer of a file open in the code editor. The file on disk was intact and nothing was saved, so it is a display-layer mixing rather than a write path. Not reproduced and not diagnosed — logged with the two places the streams can meet (`CodeSurface` is shared between the task panel and the editor; the editor keys by path while panel stores key by panelId through useGlobal/usePanelMemory) and a first move that distinguishes them: whether the buffer is polluted or only the render is, which Cmd+S and a tab reopen answer immediately. Recorded rather than guessed at further. An editor that can show content the file does not contain is a correctness problem even when it never writes, because the instinct on seeing it is to save. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bf44a4cfab |
resolving a member's task symlink needs their identity too
One layer below yesterday's fix, and it looked identical on screen: the job was
found, then declared to have written nothing.
`loadBackgroundTask` resolved the located path with `realpathSync`, as the
platform. Resolving a link needs `x` on every directory above it, and
`/tmp/claude-<uid>` is `drwx------` — so it threw EACCES on an INTACT link, and
the catch below it reported that as a dangling symlink and returned null. The
tray polls, gets `{kind:'pending'}`, and shows "Nothing written yet" forever.
The lookup fix could not have exposed this: it made the file findable, which is
precisely what let execution reach the line that then threw it away.
`realpath -e` rather than `readlink -f`, because `-e` requires every component to
exist — that keeps a genuinely dangling link reporting as one instead of
resolving to a path that is not there. Verified against symlink, plain file,
dangling link and missing path: `realpath -e` and `realpathSync` agree on all
four, so the owner path is unchanged.
Audited the rest of claude-sessions.ts for the same shape. Every remaining
mention of `statSync`/`readdirSync`/`Bun.Glob` in that file is a comment
explaining why it is NOT used.
Live coverage extended: the member resolves their own link, the platform gets
null. Skips without OFFICER_TEST_MEMBER.
tsgo clean, frontend builds, 865 pass / 7 fail unchanged, 7 skips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
6bee6b856e |
a member's background job can be read and stopped
A member started `bun dev`, watched it run, and got no logs at all — then
`{"stopped":false,"reason":"no such task"}` from the Stop button. Two symptoms,
one cause, and it is the same one `read-as-user.ts` was written for.
`findTaskOutput` globbed `/tmp/claude-*/…` as the platform's own uid.
`/tmp/claude-<uid>` is `drwx------` (checked, not assumed), so for a member that
directory cannot even be traversed. A glob that cannot traverse does not throw —
it returns an empty iterator. Both callers read that as "no such task": the log
view showed "Nothing written yet" forever, and Stop refused an id that was
perfectly real.
Every other filesystem access in that module already goes through the as-user
helpers. This one path never did, and it was invisible for as long as only the
owner used chat.
So the lookup moves into `findPathAs`, and Stop runs as the member too — both
halves of it. `fuser` reads `/proc/<pid>/fd`, which only the process's own user
and root may open, so as the platform it would have found no pids and reported
the job already stopped; the kill after it would have been cross-user EPERM,
swallowed by a catch. Neither would have said anything.
── The exit code is ignored, and that is the point ──
The first version of this fix located the file and threw it away. `find` exits 1
when it cannot descend into something, and searching `/tmp` from ANY identity
hits another account's `drwx------` — it prints the match on stdout first, then
returns 1. Treating that as failure reproduced the original bug through a new
mechanism. Caught by testing the owner path against a real task file rather than
assuming the refactor was behaviour-preserving; a missing root still exits 1 with
empty stdout, so absence still reads as absence.
Owner and member now take the same `find`, deliberately: one set of matching
semantics, rather than a glob for us and a find for them, which is how a bug ends
up reproducing on one account and not the other.
Verified on the owner path here against a live task file. The member path is
covered by `read-as-user.live.test.ts` — same opt-in shape as
`spawn-as-member.live.test.ts`, asserting the two identities DISAGREE, which a
world-readable tree would not satisfy. It cannot run on a machine with one
account, so it skips here and needs OFFICER_TEST_MEMBER on the host.
tsgo clean, frontend builds, 865 pass / 7 fail unchanged, 3 new skips.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
23bfacf412 |
a missing plugin can no longer stop the platform booting
A server died on `Cannot find module '../../../../plugins/music/db/schema'` before a line of its own code ran. The pull that broke it was the one untracking `plugins/` — git deleted those directories from the working tree, and the gitignored `plugin-schemas.gen.ts` still named them. The barrel being wrong is NORMAL. It is written by `db:push` and by installing a plugin, and nothing rewrites it when a directory goes away by other means: a pull, `git clean -xfd`, `rm`. It describes a machine, not the project, which is why it is gitignored in the first place. The defect was not the stale file. It was that a file allowed to be wrong sat in the import graph of the process that must always start — via `db.ts` → `schema.ts` → the barrel. An import graph is resolved before `main`, so this was not catchable, loggable or survivable. Everywhere else the plugin system already holds the line: `refreshPluginMounts` isolates a bad plugin, `discoverPlugins` reports a broken manifest instead of throwing. This was the one remaining path that could take the whole server down, and it took it down. So the two consumers get their own entry points. `schema.ts` keeps the core tables and is what the runtime imports. `drizzle-schema.ts` re-exports it, adds the generated barrel, and is read only by drizzle-kit — which regenerates the barrel before every run and can afford to fail loudly on a genuinely broken plugin. `drizzle.config.ts` points at the new one. Verified by reproducing it: with the barrel naming a plugin directory that does not exist, importing the server's db module now succeeds while importing `drizzle-schema.ts` still fails with that exact error — so the runtime is immune and drizzle-kit's strictness is intact. First attempt at that test was worthless, since I "poisoned" the barrel with a path that existed here; redone with an absent one. `bun db:gen` then loaded the new entry and emitted both core and plugin tables (music_*, offscale_servers), which is what proves `db:push` still works. Pulling this is enough to boot a server in that state — the stale barrel stops being loaded rather than needing to be repaired. tsgo clean, frontend builds, 865 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
08d725bfb3 |
the background job button wears the amber a running job wears
Not white. `toneText.warning` — hsl(43 96% 56%), the same amber a running task chip shows two rows up, so the control and the thing it produces read as one feature rather than two. Taken from `toneText` rather than typed as `text-warning`, so it cannot drift from the chips it is matching. The name is misleading in this one place: nothing here is a warning, it is just where that colour lives in the palette. Dialog title icon follows, same reason as the glyph did. tsgo clean, frontend builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a78541a341 |
circle-play for the background job button, at full strength
White rather than muted, 18px rather than 16. Its neighbours on that row are pickers — they report what is already selected — and this is the only control there that does something, so it should not be wearing the same recessive grey as a label. The glyph was a radio tower, chosen because a play button implies one-shot. That reasoning was too clever: most of what gets started here is a long-running process, and a watcher is still something you press start on. Recognisable beats precise at this size. The dialog's own title icon changes with it. A button and the thing it opens wearing different glyphs is a small lie about them being the same feature. tsgo clean, frontend builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f580d845ac |
running jobs sit ahead of finished ones in the tray
The tray was newest-first, full stop. So: ask for a long-lived job, talk for a while, and every short-lived job an agent starts along the way pushes it one place further right — until the one thing still running is the one thing off the end of a strip that scrolls. Exactly backwards. What falls off the end should be what you are not watching. A finished chip is a receipt: it exists so a notification that landed while you were reading something else is still there when you look up. A running chip is a live thing you may need to open or stop. Ordering them together by age treats those as the same kind of object, and the strip's overflow turns that into the receipts slowly evicting the job. So `orderTasks`: running first, newest-first preserved within each group. Two passes rather than a comparator, so it does not lean on sort stability and reads as the partition it is. Applied after the FINISHED_KEPT cap, not before. The cap asks which finished chips are still worth keeping, which is a question about age; where they then sit is a different question. Pinned chips inherit the same order, so a pinned running job leads its row too. Cosmetic, as asked — no behaviour changes, nothing new is hidden or dropped. 5 tests, tsgo clean, frontend builds, 865 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
2b70a5700e |
the code editor stops underlining correct code
Not spell check — Monaco's own TypeScript worker, misconfigured in two
independent ways. Both are visible in `monaco.contribution.js:272`, where the
defaults are `{ allowNonTsExtensions: true, target: Latest }` and
`{ noSemanticValidation: false }`.
── 1. It was reading JSX as TypeScript ──
`tsWorker.js:93` decides a file's script kind from the SUFFIX of its model URI:
`ts`/`tsx`/`js`/`jsx`, and otherwise falls back to TS. `<Editor>` was given no
`path`, so its model was `inmemory://model/1` — no dot, no suffix, TS. JSX is
illegal in a `.ts` file, so every tag in the file was a syntax error. That is
the wall-to-wall squiggling in the screenshot.
Passing the real path gives the model a `.tsx` URI. `jsx: ReactJSX` is set too;
both are needed, since the extension alone still errors without the option.
── 2. It was type-checking against a file system it cannot see ──
Semantic validation is now off, and this is the part worth stating plainly.
Monaco runs in the browser; the files are on the server behind the file API.
There is no `node_modules` to resolve `react` from, no `tsconfig.json` to read
paths out of, no way to follow a relative import. So every import resolves to
nothing — which is where "Cannot find module './logo.svg'" came from. Not a
mistake in the file: a checker with no file system.
Wrong errors are worse than none. They teach you to ignore the colour, and then
the one real problem underlined the same way goes unread. Monaco's own authors
already made this call for JavaScript — `javascriptDefaults` ships with
`noSemanticValidation: true`. This extends it to TypeScript for the same reason.
Syntactic validation stays ON: an unclosed brace needs only the buffer in front
of it, and with the extension finally right it is answered correctly.
Real semantic checking would mean shipping the project's dependency types into
the browser — a language-server-over-websocket feature, not a config change.
tsgo clean, frontend builds, 860 pass / 7 fail unchanged. Not verified in a
browser: I cannot see the editor render.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
e2f7a3f091 |
the preview reloads for jobs you started, not jobs the agent started
Yesterday's change bumped `background-job:changed` on every `task:started`. That was wrong in a way the commit message admitted and then waved through: agents start background jobs constantly while working — a test run, a build, a long grep — so the reload trigger had moved from "every edit" to "every incidental job" without getting meaningfully rarer. Same churn, new cause. The jobs worth reacting to are the ones started from the background-job dialog, because that is where somebody says "run the dev server". ── Arm and claim, not an id ── The dialog cannot name the task it is about to create: it sends a prompt, the agent works out the command, and the harness assigns the id. Nothing links the two but sequence. So the dialog ARMS, the next `task:started` claims the arm and records its id, and from then on completions are matched by id — however long the job runs. One arm, one claim: a second job in the same turn is not ours. The arm expires after 30 minutes, because the preamble tells the agent to ask before arming anything ambiguous, so a legitimate claim can be minutes late — but an abandoned conversation would otherwise leave the arm sitting there to be taken by whatever an agent started next. A job stopped by hand is adopted regardless of who started it. That is the one place the rule bends, and it bends towards the user having clicked something. Module state rather than a channel: it is read inside the websocket handler to decide whether to bump, and nothing renders from it. `createBackgroundJobOrigin` is exported so tests get a fresh instance instead of a reset that production code could also call. Still over-triggers within that set — any dialog-started job reloads every preview. Nothing observable links a preview's URL to a job, since the parent cannot see inside a cross-origin iframe. 9 new tests, tsgo clean, frontend builds, 860 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
4ced2983a6 |
the preview reloads when a job restarts, not when a file changes
Restarting the dev server leaves the iframe holding a dead HMR socket. The page keeps rendering and looks completely alive — it has simply stopped receiving updates. So the agent edits a file, nothing moves, and there is no way to tell whether the edit failed or the connection did. Reported after exactly that sequence: stop, start, ask for a change, watch nothing happen. A stale preview that is indistinguishable from a working one is worse than an obviously broken one, because you debug the wrong thing. ── Which signal, and why not the obvious one ── `preview:refresh` already exists and is bumped on every turn that touched a file. Subscribing to it would fix this and ruin the feature: a reload throws away scroll position, form state, and whatever route you had navigated to inside the app — on every edit. HMR exists precisely so that does not happen. So a new channel, bumped on `task:started` and on task completion. A job coming up may be a dev server coming back; a job going down may be it going away. Both are moments a preview pointed at it is now lying. Neither fires on an edit — this is a few times a session, not once a keystroke. Stated rather than hidden: it OVER-triggers. Any job starting reloads any preview, not only the one serving it. That costs one reload on an unrelated watcher, which is the cheaper of the two errors. The parent process cannot see inside a cross-origin iframe, so there is no way to ask whether its socket is alive. The job lifecycle is the closest observable proxy, and it is exact for the case that prompted this. tsgo clean, frontend builds, 851 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
6b21d4b8bd |
duration is one checkbox, because two of the three options were the same thing
"This session" meant nothing. The backend deliberately holds the agent process alive while a background job is running, so closing the browser does not end one — "this session" and "until stopped" were one behaviour wearing two labels, and offering both implied a difference that does not exist. So there is one real choice, and it is a yes/no: bound it by time, or run until stopped. [ ] Stop after [60] minutes Unchecked is the default and the common case. Checked exits when the time is up whether or not it fired, which is the only thing a clock can usefully mean here. This also removes a note that had become false. The dialog used to say "all of these end if the session does" — written from the process tree, where the job is a descendant of the agent process. True as far as it went, and wrong in practice because of the keep-alive. It now says what each choice actually does instead of what the ancestry suggests. Still true, and unstated because it belongs somewhere else: `pm2 restart officer-claude-code` ends every running job. That is a deploy-time fact, not something to put in a composer. tsgo clean, frontend builds, 851 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
1a9b162615 |
a stopped job stays stopped, and Stop is a real button when expanded
Two things from stopping one by hand. ── It restarted itself ── Pressing stop produced the exit notification, and the agent read that as a crash: it brought the server back up, then wrote three paragraphs theorising that "something outside this conversation sent that SIGTERM" and counting it as the third external touch on the repo today. It was not wrong about the signal. It could not have been right about the cause, because the stop button did not exist when the preamble was written, and the preamble said only "report" — leaving what to do with an exit entirely open. So it now says: on exit, one line, and STOP. Do not restart. Do not diagnose. Do not theorise about what else on the machine might have touched it. A job I stopped that comes back on its own is the opposite of a stop button — and an exit is at least as likely to be me as a failure now that pressing a button is how you end one. Deliberately not written as "ignore exit code 143": the phrasing is about intent, not signal numbers, so it holds whether the job dies by SIGTERM, SIGKILL or its own hand. ── Stop, labelled, in the expanded panel ── The chip keeps its icon; the panel gets a bordered button that says "Stop". The panel is where you go to decide whether something should keep running, and the control that ends it should not be a glyph you have to hover to identify. Both appear only while the task is running. tsgo clean, frontend builds, 851 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
048e718b21 |
a stop button on running background jobs
Killing a job meant asking the agent in words — a whole turn to say "please stop
that", and only possible while the agent is responsive. Now it is a button on the
chip.
── Finding the process ──
The platform does not own these processes. Claude Code starts them and nothing
records a pid. What it has is the file the job streams into, and the job is still
holding that file open — so `fuser` gives the pid, and the file is resolved
through the SAME scoped lookup the read path already uses: the id is validated
against TASK_ID_RE, then matched only under this caller's own directories. An id
that resolves to nothing kills nothing.
Verified end to end rather than reasoned about: a stand-in job holding its output
file open, `fuser` finding it, `{"stopped":true}`, process gone.
SIGTERM, not SIGKILL — a dev server with children should get the chance to take
them down with it. SIGKILL orphans them and leaves the port bound, which is worse
than a stop that takes a second.
── Two things it deliberately does not do ──
It does not dismiss the chip or write a `stopped` status locally. The real end
arrives the way every other end does — the harness sees the exit and the
transcript gets the row — so faking it would be a guess that usually agrees with
reality and sometimes does not. A stop that fails leaves the chip running, which
is the truth.
It does not offer to stop a SUBAGENT. Those write a `.jsonl` transcript rather
than holding a log open, so there is no fd to trace; it says so instead of
pretending.
`Square`, not `X`. X on the same chip means "close this", and confusing "hide the
chip" with "kill the process" is the one mistake worth designing out — which is
why stop appears only on running tasks and dismiss only on finished ones.
tsgo clean, frontend builds, 851 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
3512b06d5e |
background jobs: start silently, say one line
Asking for `bun dev` produced a preface ("Starting it exactly as specified…"), the
call, a read-back of the output to confirm, a paragraph explaining what resolved
to what, and then two unsolicited notes. Five kinds of output for a request whose
whole appeal is that there is nothing to discuss.
The preamble already said "tell me in one line" and was talked past, because it
described the ending without forbidding the rest. Now it names each thing:
- nothing before starting — no preface, no restating the ask, no announcing
that the instructions are about to be followed
- one line after: what is running, its id, how to stop it. Not notes, not
observations, not what was chosen or why, not anything noticed in passing
- a question is the ONLY thing allowed to come first
And it no longer reads the output back to check the job started. That was work
the harness already does: if it fails, the exit arrives on its own — which is the
entire reason for using the tracked mechanism. Verifying by hand adds noise to
the one case where nothing is wrong, and adds nothing to the case where something
is.
Silence stays conditional, not absolute: an unclear condition must still be
settled in conversation before anything is armed.
tsgo clean, frontend builds, 851 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
f0c93fa716 |
a background-job button in the chat composer
A `Radio` button between the harness and model selectors opens a small composer:
you write one sentence, the agent receives it under a preamble of mechanics that
never appears in your bubble.
── Four orthogonal choices, not modes ──
who writes the command a literal one, or an intent the agent works out
is there a condition always PROSE — a condition worth watching is a sentence
and worth arguing about before it arms, not a predicate
typed into a box
does firing end it exit-is-the-notification, or act-and-keep-going
how long this session / N minutes / until stopped
Ticking the watcher forces prompt mode rather than allowing a combination that is
then rejected on submit.
── The rule that inverts, which is why the checkbox exists ──
"Stay silent while waiting" is right when output is DEFERRED to exit — it all
lands in context at once. For a watcher that never exits, output streams to the
pinned pane and never reaches context, so a line per event is the point rather
than a cost. The preamble says the opposite thing in each case; with one rule it
would have suppressed the only signal a persistent watcher gives.
── Hidden without hacks ──
`sendWithHiddenPrefix` reuses the display-text argument `sendPrompt` already
takes: the agent gets preamble + text, the transcript shows text. A NEW
`hiddenPrefix` field rather than the existing per-prompt `prefix`, which carries
attachment references — those are part of what you said and belong in the bubble.
── What it says out loud ──
"If what I asked for is not completely clear, ASK ME FIRST." A wrong condition
fails silently — never fires, or fires constantly — and is discovered days later.
Arming it late costs a minute.
And the duration note does not promise what it cannot keep. Traced the process
tree: the job is a great-grandchild of the claude process, so `pm2 restart
officer-claude-code` kills every watcher on the box. "Until stopped" therefore
reads "all of these end if the session does" rather than "forever". A job that
must outlive deploys belongs under PM2, not under a chat.
cwd comes from the panel, so nothing has to be typed — the dashboard rooting from
earlier today.
tsgo clean, frontend builds, 851 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
5c40d4423d |
app preview: a panel that points an iframe at a running app
A dashboard can now hold chat, the code editor, the file browser and the app itself — the last piece of working on a project without leaving Officer. ── Why this is ~200 lines and not 560 ── The version deleted on 2026-07-31 spawned `bun dev` in a project directory, found a free port and proxied it under `/api/dev-server-proxy/<id>/`. That prefix is what cost the money: HTML, JS and CSS rewritten; a script injected into the page to monkey-patch fetch/XHR/WebSocket so runtime URLs got the prefix too; a Referer fallback for chunks that resolved at the wrong depth; a websocket bridge for HMR. All of it faking an origin. On a machine with a proxy in front — nginx on edge.pertento.ai, wildcard subdomains — the app is ALREADY served at the root of its own origin, and the browser is already on the tailnet. So there is nothing to fake and no server side at all: no route, no socket, and therefore no permission-registry entry. The old code is not obsolete and is not being thrown away. An install with no proxy in front still has an app on localhost that the browser cannot reach, and that is exactly what it solves. It is at `188b45c1^`; the note is in TODO.md. ── What it does ── Holds a URL per panel, renders it, reloads it, opens it in a real tab. The URL lives in dashboard state so it survives a reload, and is shared LIVE between header and body — the header writes and the body reads, so claim-once would mean typing a URL changed the header and nothing else. The reload counter is deliberately not persisted: it is a signal. Reload remounts the iframe by key rather than calling `contentWindow.location .reload()`, which throws cross-origin. Replacing the element re-requests the URL, which is the same thing from the outside and the only move the parent is allowed. `allow-same-origin` is set and has to be: without it the framed app gets an opaque origin and no localStorage, and it authenticates with a JWT it keeps there. `normalizeUrl` accepts a bare host as https and refuses javascript:, data: and blob: — an iframe src with `javascript:` executes in the PARENT's context. The owner typing in their own panel is not an attacker; it costs one line and removes the category. 5 tests. ── Two iframe facts worth knowing before testing ── Storage is PARTITIONED by top-level site, so the login inside the panel is separate from the login in a tab: expect to sign in once, in the panel. A page can refuse to be framed (X-Frame-Options, CSP frame-ancestors) and renders blank with only a console error. If that happens it is nginx's config, not this code — which is why "open in a new tab" is in the header rather than left to copying the URL out. tsgo clean, frontend builds, 851 pass / 7 fail — +5 new, same 7. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
20aa0cc880 |
a deleted file stays open, says so, and can be saved back
Keeping the tab when an agent deletes the file was deliberate — closing it would
let an `rm -rf` of a build directory take unsaved work with it — but it was only
half the idea, and the missing half made it worse than useless:
the tab looked identical to a live file, and
you could not SAVE it, because the editor thought nothing had changed
So the buffer was the only copy left, and the one action that would rescue it was
locked until you typed a throwaway character to force the dirty flag. Reported
from a real session.
VS Code's answer, and the right one: a file that has left the disk is DIRTY,
because the buffer now differs from what is there (nothing).
markMissing missing: true + isDirty: true — save works immediately
the tab name struck through, amber icon instead of the dirty dot
markSaved clears `missing`, because saving PUT IT BACK — leaving the warning
up would make the fix look like a failure
reloadFile clears it too, for a file that reappears from elsewhere
That makes "save recreates the file" an informed recovery rather than the accident
it was: the tab says the file is gone before you press it.
Not a bug, and checked rather than assumed: the report that a tab showed "my
previous content on top of the agent's" was the file genuinely containing both.
On disk it reads `- Sidecasadasrs assumed up` — `Sidecars` with `asadas` typed
into the middle of it. The buffer had been saved over the deleted file, the agent
then edited that file, and the editor was showing the truth.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
f534b818b9 |
resuming a conversation needs its transcript, not just its id
Switching to an existing chat showed the right title and an empty pane. The session was correct; none of what was said in it was there. Passing the id as `initialSessionId` seeds the socket's resume handshake, so the AGENT continues the right conversation — but nothing ever fetches the messages, so the UI has none to draw. The two halves disagreed silently: send a turn and it would have carried on correctly above a history you could not see. The /chat screen has always done it properly, and this now does the same: `resumeSessionId` + `initialMessages` + `paginate`, from `GET /chat/sessions/:id?limit=20`. Only the tail is loaded — transcripts get very long — and `total`/`offset` tell the chat where that window sits so scrolling up pages the rest in. ── Fetched BEFORE the chat mounts, not after ── `useChat` seeds its state from the options given on its first render, so loading afterwards is too late: the messages would arrive at a hook that has already decided it has none. The panel therefore holds off rendering while a transcript is in flight, which also avoids showing an empty conversation for a moment and then replacing it — that reads as history being lost and then found. A stale id (transcript deleted or pruned) opens a NEW conversation rather than an empty pane, because an empty pane is indistinguishable from a conversation whose history vanished. This is the same class as the cwd bug an hour ago: the id was right, the wiring was right, and the thing that makes it visible was never asked for. tsgo clean, frontend builds, 846 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
5998492dcd |
a chat panel opens on the last conversation, not a blank one
A panel that has never chosen now continues the newest conversation in its directory. Opening a dashboard onto a folder that already has history and starting a blank chat is the wrong default — the history is why you are there. It is also the case that prompted this: the conversation existed before the panel did. ── Three states, because two collapse wrongly ── undefined never chosen -> the newest conversation in this directory null "New chat" pressed -> a fresh one string that conversation `undefined` and `null` were the same value until now. Left that way, pressing New chat would set null, the default would read it as "nothing chosen", and the panel would snap straight back to the newest conversation — the button would look broken. ── Two races, both closed ── The panel does not mount until the session list has answered. Otherwise it starts a NEW conversation, the list arrives, the default applies, and the chat remounts onto something else — discarding anything typed or sent in the gap. And the id recorded on mount is only ever a REAL one. `chat.sessionId` is null for a moment while a resumed session connects, and writing that null would turn "never chosen" into "asked for a new chat", so the NEXT reload would open blank — a bug that only appears one reload later, which is the kind that gets blamed on something else. Asking for a new conversation is something the header says explicitly; this effect only reports what the harness decided. Once the default is applied the harness reports its id and it is recorded, so it stops being derived and becomes this panel's choice — "latest" the first time, "last used" thereafter. tsgo clean, frontend builds, 846 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8de6088546 |
the session list was asking for a directory that does not exist
Your conversation was there the whole time. The dropdown was empty because I sent
the wrong kind of path.
what the header sent -Tests-platform no such directory
what is on disk -home-pastilhas-Tests-platform 1 transcript
Two conventions live next to each other and I used the wrong one. The file
endpoints take a HOME-RELATIVE path (`/Tests/platform`) — that is what `cwdToPath`
produces and what the file browser and editor pass. `/chat/sessions` takes the
ABSOLUTE one, because Claude's folder name is
`cwd.replace(/[^a-zA-Z0-9]/g, '-')` applied to the directory a turn actually ran
in, and a turn runs in a real directory.
`cwdOf` uses the query value verbatim (`query('cwd')?.trim() || home`), so nothing
rejected the relative form — it just resolved to a slug for a directory that has
never existed, and answered an empty list rather than an error. The failure had no
symptom beyond "no conversations", which is also what a genuinely empty directory
looks like.
Joined against `useChatPwds().defaultCwd` — the caller's home as the SERVER sees
it, and the same value `cwdOf` falls back to — rather than guessing at where home
is a second time.
Verified end to end: `~/Tests/platform` now resolves to
`/home/pastilhas/Tests/platform`, whose slug is `-home-pastilhas-Tests-platform`,
which is a directory that exists and holds the transcript.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
465435ccf1 |
a chat panel picks from the conversations in its dashboard's directory
A dashboard rooted in ~/Tests/platform now has a session picker in its chat panel's header: every conversation started in that directory, newest first, plus New chat, rename and delete. ── Almost all of this already existed ── `GET /chat/sessions?cwd=` returns conversations for a working directory, merged across Claude and OpenCode. It is not a registry Officer maintains: Claude writes 每 transcript to `~/.claude/projects/<cwd-slug>/`, so "the conversations belonging to this dashboard" is how they already sit on disk — the same ones the terminal `claude` sees. `useClaudeSessions` already wrapped list, rename and delete for the /chat screen. The panel header is new; nothing under it is. ── The one design correction ── Which session a panel is on is NOT `usePanelMemory`. That hook claims its saved value once and then ignores the bag, because the editor and file browser are the only writers of their own state and hearing it echo back would tell them to reopen what they just closed. Here the header writes and the body reads — two components with no props between them — so the value has to stay LIVE. Claim-once would have meant picking a session changed the label and nothing else. It is the same dashboard-state bag, read live, so it still survives a reload. Switching remounts the chat on its key, which is what the existing comment calls "the honest way to say this is now a different conversation": `useChat` seeds from the first `initialSessionId` it sees and the resume handshake sends whatever is in that state on connect. A NEW chat is `null` until the harness names it — only the harness can — and the id is recorded on arrival, so "new chat, say something, reload" returns to that conversation rather than a third one. Deleting the conversation on screen points the panel at a new one rather than at a transcript that no longer exists. ── Left alone, and one thing to know ── `agent_panels` is untouched: a named agent still wins the session choice outright, since it is one conversation forever by definition. The picker is for the ordinary case. The email screen mounts ChatPanelWrapper too, so its chat now also remembers its session instead of starting fresh each visit. That is a behaviour change to a screen this work was not aimed at — better in my view, but say if not, and it scopes to dashboards in one line. tsgo clean, frontend builds, 846 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a871c055bf |
fix: one empty write and the editor could never save its tabs again
Reported not working, and the database said exactly why:
{"editor":{"p-1786832482923-77":{"open":[],"active":null}}}
The write worked. It wrote EMPTY, on the first mount before any file was open,
and from then on the panel was locked:
- an empty saved value is truthy
- the restore effect bailed on `open.length === 0` WITHOUT marking itself done
- the write guard was `if (restored && !didRestore.current) return`
so every later save was blocked by a restore that had already decided not to run.
Self-inflicted, and the guard was mine from two commits ago.
Underneath it was a second ordering bug that would have bitten even with the first
fixed: the restore is ASYNC — it reads each file — while the write effect runs on
the same mount, sees an empty `files`, and persists over the list it is in the
middle of reopening. Marking the restore done synchronously would just have moved
the failure.
Both are now one flag. `restoreDone` is state, set when the restore COMPLETES —
including when it completes by having nothing to do — and the write waits on it.
Nothing is persisted until the restore is genuinely finished.
Cleared the poisoned `editor` bag from the live row so the next test starts clean
rather than against state the old code had already wedged.
Worth naming the pattern: the guard conflated "there is saved state" with "a
restore is pending". Those differ exactly when the saved state is empty, which is
the state every panel starts in — so the bug was guaranteed rather than unlucky.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
74495c25ab |
a file browser panel reopens where you left it
Navigate into a subfolder of a dashboard's directory, refresh, and you were back
at the top. The /files screen keeps its folder in the URL and never had this; a
panel had nowhere to put it.
── Made shared, because chat is next ──
The editor's tab memory from the last commit was one panel's version of a pattern
the terminal had already invented. Rather than write a third, `usePanelMemory` now
holds the mechanics — claim once, key per panel, drop on real close — and each
panel supplies only a payload. The editor moved onto it and lost 50 lines; the
file browser stores `{ path }`; chat will store whatever chat needs.
Restoring is SYNCHRONOUS, in the initial state rather than an effect, and can be:
`WorkspaceView` renders nothing until dashboard state has loaded, so the
remembered folder is already there on the first render. An effect would list the
base folder first and visibly jump to the right one.
── Two ways it could strand you, both closed ──
A remembered folder OUTSIDE the panel's base is discarded on read. A dashboard
scoped to ~/Tests must not reopen at ~/other because it was rescoped or the folder
moved. The existing guard catches that after the fact; this stops it being
requested.
A remembered folder that no longer EXISTS was the new failure this feature
introduced — the listing throws, a toast appears, and every reload lands in the
same dead folder, because that is what was remembered. The first listing now falls
back to the base and rewrites the memory. Deliberately first-listing-only: later
in a session a failure is far more likely transient, and bouncing someone out of a
deep folder over one bad response is worse than the error they can already read.
`files` registered in PANEL_STATE_PREFIXES, without which the PATCH is a 400.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
95b83fb29b |
a code editor panel remembers its tabs across a reload
Refreshing the page emptied it. You came back to "Open a file from the explorer to
start editing" with no trace of what you had been doing — two tabs open, one of
them the notes you were writing in.
The terminal solved this shape years ago: a `panelId -> sessionId` map kept in
dashboard state, keyed `ws-{prefix}-{dashboardId}`. This is that map with a
different payload, deliberately the same shape so there is one pattern rather than
two to compare. `editor` is registered in PANEL_STATE_PREFIXES — an unmatched key
is a 400, not a silent 200, which is the branch that exists precisely so a new
prefix cannot vanish quietly.
── Paths, not contents ──
The disk is the truth. Restoring a remembered BODY would show a version that may
be hours stale, or resurrect a file something has since deleted. Each path is read
fresh on restore, in the order you left them, and one that no longer reads is
dropped rather than opened as an empty buffer named after a missing file.
The cost, stated rather than hidden: unsaved edits still do not survive a reload.
They did not before either — the whole tab went. Keeping them means persisting
buffers, which has its own hard question (the disk AND the buffer have both
changed — now what?) and is not smuggled in here.
── The two ways this goes wrong, both guarded ──
Reading the saved set more than once would fight the user: every tab they open
writes into that same bag, so a later read arrives as an update telling them to
reopen what they just closed. It is claimed once, on the first render that has it.
Writing before restoring would persist an empty list over the state it is about to
read — first render, no tabs yet. The write is guarded on the restore having run.
Also: a panel closed for good drops its entry, via `usePanelClose`, which fires on
a real close and not on a drag, a swap or a mobile panel switch.
Per PANEL, not per dashboard, so two editors side by side keep separate strips.
Not wired on the /code-editor screen: `?file=` already survives a reload there.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
dc3841a877 |
the code editor refreshes itself, and Cmd+S works
The file browser has updated itself at the end of an agent turn for a long time,
because it listens to `files:refresh-signal`. The editor did not, and sat showing
whatever it read when you opened it.
Now it does, plus a button in the Explorer header for a change made somewhere the
signal does not reach — a task, a terminal, another machine. Two triggers, one
behaviour:
the tree re-lists, including every EXPANDED folder. A collapsed one has
nothing on screen to be stale, and re-listing all of them on every
turn is a burst of requests with nothing to show for it.
open files re-read, and only those with no unsaved edits.
── What a refresh must never do ──
Overwrite unsaved work. A dirty tab is skipped entirely: it keeps its edits and
its dot, and does not participate. "Reload everything" is the obvious
implementation and it would silently destroy the thing you were in the middle of.
A DELETED file keeps its tab too, rather than closing underneath you — content
intact, and saving writes it back. An agent doing `rm -rf` on a build directory
must not take your unsaved notes with it.
Content arrives through `executeEdits` with a full-range replace (checked in
@monaco-editor/react rather than assumed), so a refresh keeps your cursor and your
undo history. `setValue` would have reset both.
── The bug that made all of that pointless ──
Cmd+S did nothing. Monaco keeps the callback it was handed at mount, and `<Editor>`
only remounts when the file PATH changes — so the closure was built on the render
where the file was OPENED, with `isDirty: false`, and `handleSave` returns early on
a clean file. Open, type, save: no toast, no error, dirty dot stays. It reads
through a ref now.
That one matters here specifically: a file you cannot save stays dirty forever, and
a dirty file is skipped by every refresh. The feature above would have appeared to
work and then quietly stopped for the file you were actually editing.
Inferred from the code, not observed — worth confirming by hand.
tsgo clean, frontend builds, 846 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
a7046704d5 |
a code editor panel opens at its dashboard's folder
A dashboard scoped to ~/Tests/platform showed exactly that in the editor's header, above an explorer listing the HOME directory. The two halves of one panel disagreed because only one of them asked: `CodeEditorHeader` reads `cwd` from the workspace, and `CodeEditorPanelWrapper` — three lines — never touched it. It now passes `cwdToPath(cwd)` as `initialPath`, which is what `FileTree` lists from. Still no `urlState`: a dashboard can hold two editors and one `?file=` would drive both. That reasoning, and the shape of the fix, come from FileBrowserPanelWrapper, which had it right already — which is why the file browser was correct in the same dashboard. ── One conversion instead of three ── `cwd` → path existed twice, spelled differently, and the two disagreed: cwd.slice(1) '' -> '' '/abs' -> 'abs' both wrong cwd.replace(/^~\//, '/') '' -> '/' '/abs' -> '/abs' both right An empty cwd gave the file endpoints an empty string, which lists nothing rather than failing — the quiet kind of wrong. Writing a THIRD copy for the editor is what prompted collapsing them: `cwdToPath` now lives beside `useWorkspace`, with 6 tests including the tilde-inside-a-name case that a careless regex would rewrite. Swept the rest rather than assuming this was the only one: all three panel wrappers now read cwd, and the terminal already did. tsgo clean, frontend builds, 846 pass / 7 fail — +6 new, same 7. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
15cc74bb1e |
creating a dashboard raced itself into a 500
"Could not save that change — ws-layout-platform was not written — Internal Server Error", on a dashboard that had in fact been created. `upsertDashboard` was update-then-insert, which is a read-then-write race, and creating a dashboard walks straight into it: the client sends `workspaces` (the list) and `ws-layout-<id>` (the layout) as two SEPARATE PATCHes, and both call this. Both found no row, both INSERTed, and the loser hit the primary key. The surviving row and the failing insert were stamped one millisecond apart in the log, which is what gave it away — this was never a name collision. One statement now, `ON CONFLICT DO UPDATE`. `set` carries only the fields the caller passed, so whichever request lands second writes its own column and leaves the other's alone. The two orderings become equivalent instead of one of them fatal. Proved against the real table rather than reasoned about: two plain inserts, concurrent fulfilled, rejected <- the reported 500 two upserts, concurrent fulfilled, fulfilled The `where` on the DO UPDATE is not decoration. `dashboards.id` is a GLOBAL primary key fed by a slug, so two accounts naming a dashboard the same thing collide, and an unguarded upsert would let the second silently take over the first's row. Verified on a scratch table that a non-owner's upsert is DROPPED rather than applied or thrown — the row is left untouched. This machine has one account, so that path could not be exercised end to end; the SQL semantics were. That is still the wrong data model — the real fix is a composite key — but it now fails by refusing rather than by handing someone another account's dashboard. tsgo clean, 840 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
9700959c9e |
todo: files routing — what landed, and the half that did not
The URL model is done; rows are still opaque-click divs, which was the original finding and is now easier to fix than it was. Recorded honestly rather than leaving an entry that reads as untouched work. Also recorded the pattern behind the four bugs this produced: the list of overlay params has an owner, the acts that clear it do not, and every site deciding for itself is what let the breadcrumb ship wrong an hour after the rule was written. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7359af2f55 |
the breadcrumb closes the pane too
Half a fix shipped last commit. Navigating by double-clicking a folder row closed
the open pane; navigating by clicking a BREADCRUMB did not — so the browser moved
and the viewer stayed, showing a file from a folder you had left. It failed to
load, because the name is now resolved against the folder in the path and the file
was not in this one.
The two do not share a code path. A row goes through `setCurrentPath`, which I
stripped. A crumb is a `<Link to={hrefForPath(...)}>` and never calls it — and
`hrefForPath` still carried `location.search` verbatim. Same navigation, two
outcomes, decided by which control you used.
Both strip now. Audited every site that builds a folder URL:
setCurrentPath strips — rows, search results, Show location
hrefForPath strips — breadcrumb links
legacy redirect KEEPS, deliberately: `?path=X&view=Y` is one old link meaning
"this folder, with that file open", and honouring it is the
whole point of the redirect
widget openFile sets its own view; the search it discards belongs to the screen
it is navigating away from
This is the third bug in a row from the same root — the query string having more
than one writer. The list of overlay params has an owner as of the last commit;
the ACTS that clear it still do not, which is why a `<Link>` could quietly opt out
of a rule the function next to it enforced.
tsgo clean, frontend builds, 840 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
0dc88b5119 |
leaving a folder closes what was open in it
A pane shows a file from the folder you were in. Walking into another folder kept it open, so the listing said one place and the pane said another — and the URL carried a `?view=` that no longer belonged to its own pathname. Navigating now drops the overlay params. Only those: anything else in the query is left alone, because `useGlobalQueryString` puts real state there and a wholesale reset takes it with it. ── The actual fix is that the list has an owner now ── Which params belong to the overlay was a private array inside `useFileViewerPanels`, so every other site that touched the query worked from memory. That is exactly how `onCloseViewer` came to wipe the folder along with the pane, and it is the thing TODO.md flagged as the reason a fifth handler would get it wrong the same way. `VIEWER_PARAMS` and `withoutViewerParams` now live in `files-route.ts` — a leaf with no imports, so the hook and the browser can both depend on it without depending on each other. Three readers, one list. Writing this caught a fourth site immediately: `setViewerParams` had been REPLACING the whole search since the folder left the query string, so opening a file would have discarded global UI state. It clears the overlay and keeps the rest, like everything else now does. 3 more tests, including that every key is covered rather than the obvious two. tsgo clean, frontend builds, 840 pass / 7 fail — +3 new, same 7. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7e31564c15 |
?view= survives a page load — it never has
Opening or refreshing a URL with `?view=` gave you a bare file browser and a URL
that had quietly rewritten itself to drop the param. Reported as "has never
worked", and it never had.
`useFileViewerPanels` deleted EVERY ephemeral key in a mount effect, filed under
"clear stale ephemeral params". So the page came up, the effect stripped `view`,
and the pane never opened. It arrived incidentally in
|
||
|
pastilhasandClaude Opus 5
|
98ba604aaf |
?view= is a name, not a second copy of the path
before /files/archive/Tests/platform/docs?view=%2Farchive%2FTests%2Fplatform%2Fdocs%2Fagent-coordination.md after /files/archive/Tests/platform/docs?view=agent-coordination.md The pathname already says which folder you are in. Repeating it in the query said the same thing twice, and the encoded copy was the unreadable half. ── Absolute is still read, just never written ── `resolveInFolder` takes either form. That is not politeness, it covers three real cases: links made before this change, `?ephemeral=` pointing at a generated file that may not live beside the original, and anything genuinely outside the folder being browsed. `relativeToFolder` only shortens a DIRECT child. Something nested deeper stays absolute rather than becoming `sub/b.md`, because a relative value containing a slash reads like a path when it is meant to be a name, and there is nothing to gain from the ambiguity. A near-miss is handled too — /docs2 is not under /docs. ── The one that would have broken ── The widget's Recent and Pinned lists opened `/files?view=<absolute>` and let the screen work it out. With the folder in the pathname that now means "open this file while sitting in home", which is not where the file is. It navigates to the file's folder and names it from there. All three providers resolve, not just the viewer: `ephemeral` and `ephemeral2` are paths too, and leaving them literal would have made the short form apply to whichever panel happened to be first. 6 more tests on the round trip, including the near-miss and the nested case. tsgo clean, frontend builds, 837 pass / 7 fail — +6 new, same 7. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
559560de48 |
the folder is the URL: /files/Tests/test folder
`?path=/Tests/test_folder` becomes `/files/Tests/test%20folder`. Directories only —
an open file stays `?view=`, because it is what is on top of you rather than where
you are, and that split is what keeps closing a pane from moving you.
── The landmine, found before building on it ──
`server.tsx` 404s any path ending .js/.css/.map/.png/.svg/.ico/.webmanifest/.woff2
that is not in `build/`, so it never reaches the SPA. A folder named `logo.png` is
unusual but legal, and it would have deep-linked to a 404 that reads as a broken
link rather than a rule.
Narrowed to SINGLE-SEGMENT paths, which is safe on evidence rather than by
loosening a rule: the bundler emits exactly three files, all at the root of
`build/`, so a real asset never has a second slash; and multi-segment assets
(`public/**`, `/plugins/<app>/icon.png`) are served by Bun's `routes` table before
this handler runs.
── Encoding is the part that breaks quietly ──
Per SEGMENT, never the whole path — encodeURIComponent would eat the separators.
14 tests over the round trip, because a filename may carry anything but `/` and
NUL. The ones that matter: `#` truncates a URL at the fragment if unescaped, a
literal `%` is mistaken for an escape, and malformed input must not throw
(decodeURIComponent('%zz') raises URIError, and that would take the screen down).
Parentheses stay readable — encodeURIComponent leaves them alone — so
`Kanban (copy 2)` survives as `Kanban%20(copy%202)`.
── The rest ──
- `/files` → `/files/*`. The bare route still matches with an empty splat, so every
existing link, the dock entry and DEFAULT_DOCK_PATHS keep working.
- Breadcrumbs take a `To` instead of a query string and are still real links.
- Old `?path=` URLs redirect once, in place, with `replace` so it is not a
back-button step. A bookmark from this morning still lands where it meant to.
- `setViewerParams` stopped copying `path` across, because there is nothing to
copy — the folder is the pathname and is untouched by a search-param write.
Checked and needing nothing: the page-title rule is `startsWith('/files')`, and the
dock uses react-router NavLink without `end`, so `/files/Tests` keeps the tile lit.
tsgo clean, frontend builds, 831 pass / 7 fail — +14 new, same 7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
4874c21dfd |
search results take you to a thing, they do not open it
Clicking a file result navigated to its folder AND opened a viewer pane in one gesture. Search is how you find where something is; opening it is a separate decision — so a search for a name you were merely locating left a pane you then had to close. file → its containing folder, with the row selected directory → inside it, which is what opening a folder means The file is selected rather than merely listed, so the thing you searched for is picked out of whatever else is in that folder. That makes clicking a FILE identical to Show location — one behaviour reached two ways — so the menu stops offering it twice under two names. "Open folder" now appears only on a directory result, which is the only kind that has somewhere to go into; a file gets Show location alone. `ExternalLink` went with it, since nothing was left importing it for. `handleShowLocation` is unchanged and still reveals a DIRECTORY's parent, so the two menu items on a folder are genuinely different: Open folder goes in, Show location goes to where it sits. tsgo clean, frontend builds, 817 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a84eedd126 |
zip from the folder, extract on double-click, show location
Three things from testing. ── The download zip carried the path to itself ── Selecting files in ~/Tests/test_folder and downloading produced an archive whose contents were `Tests/test_folder/…`. `POST /download` spawned zip with `cwd: rootDir` and root-relative paths, so the whole chain from home went in. Nobody selecting three files is asking for the route to that folder to be part of what they downloaded. Now it zips from the items' own folder using bare names. A MIXED selection keeps the old form, because two `notes.txt` from different folders would collide without the paths keeping them apart — the UI only selects within one folder, so that branch is a safety net rather than the case. `/compress` already did it this way; this is the same fix on the endpoint that predates it. Verified against real zip: `Tests/a.txt` → `a.txt`, `Tests/test_folder/b.txt` → `test_folder/b.txt`. ── Double-clicking an archive extracts it ── It opened a pane that rendered "Archive file" and the name you could already see in the listing. That is a step on the way to the only thing anyone opens a zip for. Extract resolves collisions, so a second double-click makes a sibling rather than overwriting. The menu's Extract stays — a double-click is not a discoverable way to learn what will happen. ── Show location ── A search result answers "here is the file"; its path underneath raises "where does this live", and clicking only ever answered the first. This goes to the containing folder, clears the search and SELECTS the row, so a folder of forty files does not leave you hunting. A directory hit reveals its parent — where is this means the folder it sits in, not the folder it is. tsgo clean, frontend builds, 817 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
5ef83ef0d0 |
say WHY a file could not be opened, and offer the thing that still works
Opening a large text file showed "Failed to read file" and nothing else. The
server had already said exactly what was wrong — "File too large to read
(max 5 MB)" — and the viewer threw it away: `.catch(() => setError('Failed to
read file'))` ignored its argument.
`hono.ts:297` renders a CustomError as `ctx.text(error.message)`, so that sentence
arrives verbatim as `ApiError.message`. It is shown now.
Guarded rather than trusted, because error paths are where surprises live. A body
is only displayed when it looks like prose: an HTML page from a proxy, a JSON
envelope from a route that sets `returnValue`, an empty string or something
300 characters long all fall back to the generic line. Checked all seven cases.
The error state also stopped being a dead end. Being told a file is too big, with
nothing to do about it, leaves the reader stuck — but the bytes are still there
and only the UTF-8 READ is capped; `/raw` has no limit. So it offers "Download
instead", which is the action that still works.
This is the same class as the empty-file bug found earlier today: the viewer knew
the answer and did not pass it on.
tsgo clean, frontend builds, 817 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
8e77b9198d |
todo: the files app needs a routing pass
Recorded next to the code-editor entry, since the owner wants both after the current test pass. The value is the verified state rather than the request: rows and search results are opaque-click divs, the breadcrumb is the one surface that already does it right and is the model to copy, a panel's folder is deliberately not addressable, and the ephemeral-vs-location param split has no single owner — which is what let onCloseViewer wipe the location along with the overlay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
31d8d72527 |
closing a file no longer sends you home
Open ~/Tests, double-click a file, edit it, save, close the pane — and the browser
was back at ~. Reported from a real session, not found by reading.
`onCloseViewer` was `setSearchParams({})`, which wipes the WHOLE query string. The
folder lives in `?path=`, so closing the viewer deleted where you were along with
what was on top of it. It also discarded anything `useGlobalQueryString` had put
in the URL.
The rule was already written down one file away, in
`useFileBrowserApp.setViewerParams`: "`path` is not one of them — it is where you
are, not what is on top of it — so it survives." Only the OPEN path honoured it.
Close now deletes the ephemeral keys by name, which is exactly what
`onCloseEphemeral`, `onCloseEphemeral2` and `onCloseChat` directly below it have
always done — it was the single outlier among four handlers.
Checked the other exits before calling it fixed: there is one `onClose` wired to
the viewer, every other handler already used the targeted form, and the
mount-cleanup effect deletes the same keys off `prev` rather than replacing the
string. This was the only wholesale wipe in the repo.
tsgo clean, frontend builds, 817 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
affe967ef4 |
todo: the code editor, and what is known about it before going deeper
Recorded so it survives a context reset rather than living in a chat message. The useful part is not the request, it is the four things established today: the screen has been unreachable for six months and so has no users, nothing about it has been verified beyond the URL plumbing, an empty-file editing bug of exactly the expected kind was already found next door, and whether 'Open in editor' should still exist is genuinely undecided. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
c945f50e60 |
creating a file just creates it — and an empty file is editable
Two halves of one behaviour. ── New file no longer navigates ── It created the file and then took you to /code-editor, which made it the only action in the browser that leaves the browser. Creating a folder does not leave the folder; uploading does not open what you uploaded. Now the file appears in the listing and that is the whole operation. Editing is the same double-click that opens anything else — the viewer's pane already has an editor in it, with a save. One way to open a thing, one place it appears. ── The bug that would have broken that on the first try ── FileViewerHeader gated its Edit toggle on `editable && content`. `content` is `string | null` and an empty file is the EMPTY STRING, which is falsy — so a file with nothing in it rendered no pencil and could not be edited. That is precisely the file you most want to edit, and it is exactly what "New file" produces: the flow above would have dead-ended on its first use. Now `content !== null`, which is what FileViewerBody already used two files away. Checked the other two truthiness gates rather than changing them blindly, and both are right: `isJson` returns false for empty (an empty string is not JSON, and JSON.parse would throw), and Read Aloud stays hidden because speaking an empty file is not a thing. `Open in editor` still goes to /code-editor and is untouched — that route is a different tool, with a tree and tabs, and today's links are the first way to reach it at all. Worth deciding separately. tsgo clean, frontend builds, 817 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
d7b602ff34 |
a real dialog for New file, New folder and Clone
`New file` shipped this morning behind `window.prompt()`, and prompt is the wrong
tool for a reason that is not cosmetic: it cannot validate. It takes whatever you
type, so the first thing you learned about a bad name was a red toast after the
round trip — and for New file specifically, the server refuses to clobber, so the
way you discovered a name was taken was by having the creation rejected.
One dialog now serves all three. It checks on every keystroke, against the names
already on screen:
- empty is not an error, just nothing to submit — no red "required" before you
have typed anything
- `.` and `..` refused; a LEADING dot is fine, because a dotfile is a real
thing to want
- `/` refused rather than quietly doing mkdir -p, which is a surprise from a box
labelled "Folder name" and is why the rename endpoint refuses slashes too
- a collision is caught before the request, and case-SENSITIVELY: this is Linux,
so Notes.txt and notes.txt genuinely coexist and refusing one would refuse a
legal name
The server keeps its own refusal. This is the courtesy; that is the lock.
Clone joined them because it was the last prompt() I had added, and the URL check
is deliberately loose: git takes ssh, git://, a local path and a host alias from
~/.ssh/config, so validating for https would break working setups to prevent a
mistake git already reports well. Only whitespace is refused.
The open state moved into `useFileBrowserApp` because two surfaces open the same
dialog — the background menu and the toolbar — and each having its own would be
two dialogs that could both be open. One mount, five call sites.
The toolbar's New folder was on prompt() before today and is now on the dialog
too, so there is no prompt() left anywhere in the file browser.
16 tests over the two validators. tsgo clean, frontend builds, 817 pass / 7 fail —
the 7 unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
84d6d7e7ce |
file browser: the eight defects from the audit
1. Kebab Cut/Copy silently did nothing, and sometimes cut the wrong rows. `EllipsisMenu` stops click propagation so opening it does not toggle selection — but Cut, Copy, Download, Delete and Compress all act on the SELECTION, which meant the kebab operated on whatever was selected elsewhere, or returned early with no toast at all. Right-click never had this because it selects first. Both now call one `ensureSelected`, on open. 2. Every menu vanished during a search. That branch had no ContextMenu and its rows are not FileItems, so right-click fell through to the browser. The folder menu is now declared once and mounted in both branches — it acts on `currentPath`, which a search does not change, so it stays meaningful. Search ROWS get their own three-item menu rather than the row menu: a hit carries an absolute path from anywhere in the tree, while every row-menu handler builds its path from the folder being browsed. Reusing it would have acted on a different file with the same name. `DirEntry.path` is optional — only search results carry one — so it is guarded, not asserted. 3. Download and Copy path now fan out over a multi-selection, the rule Delete and Compress already used. The menu downloaded one of six selected files while the toolbar zipped all six. Chat is deliberately NOT included: `chatContext` is a single path that the provider string-splits into a working directory, so a list would need Chat's contract changed. Left alone rather than half-done. 4. Read Aloud stopped offering TTS on binaries — same guard the editor got, since `text` is `getFileType`'s fallback and caught .exe and .sqlite. 5. `POST /file-browser/download` is filed as a read. It zips a selection and writes nothing; it is a POST only because a list of paths does not fit a query string. A read-level member could download a whole folder but not two files. Proved by hand that `readOnlyWrites: ['/download']` permits GET and POST /download, and still denies /download-video, /rm and /write — `isPrefixOf` is segment-aware, so the sibling route does not leak. 6. `disabled` had no use anywhere in the feature — the shared item type did not even expose it. It does now, and the first real case: `/file-browser/read` refuses over 5 MB, so Open in editor on a 40 MB log opened an editor that then failed. Hiding it would have suggested the file is not text; disabled says the true thing. 7. The grid kebab could fade out while its own dropdown was open — list view had `data-[state=open]:opacity-100` and grid did not. 8. Dead exports `getMatchingTasks` / `getMatchingAgents` removed. Both were the ungrouped input to the grouped form the menu actually renders; exporting them invited a second code path that never arrived. 9 is untouched on purpose — a plugin cannot register a menu item, and the music plugin is where that should be designed. tsgo clean, frontend builds, 808 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
e2b0d5c06b |
edit any text file, and make new ones from the empty panel
Two things, both asked for. ── Open in editor now covers text ── It was markdown and code only, because `text` is `getFileType`'s FALLBACK and so also catches binaries. That was the wrong trade: media, archives and pdf are already claimed by earlier branches, so what actually lands in the fallback is .txt, .log, .csv, .conf, dotfiles, Makefile-likes and anything with an extension the platform has never heard of. Refusing all of that to avoid one bad case cost far more than it saved. The bad case is named instead of guessed at — a ~40-entry list of extensions that reach the fallback but are not text (.exe .so .sqlite .docx .woff …). A denylist that is too short costs one bad render; a `text` test that is too strict costs the feature. Not a security control: `/file-browser/read` is UTF-8 and capped at 5 MB, so the worst outcome is mojibake. Checked against 18 names: notes.txt, server.log, data.csv, nginx.conf, .env, Makefile, script.sh, and an extensionless file all offer it; jpg, mp3, zip, pdf, exe, so, sqlite and docx all do not. ── New file, from the empty panel ── Right-click → New file takes a name WHOLE, extension included, creates it empty and opens it in the editor. The extension is what the editor uses to pick a language, so guessing one would be wrong more often than not; no extension is fine and opens as plain text. It refuses to clobber. `/write` is an overwrite, so creating over an existing name would silently empty it — the one outcome nobody wants from a menu item called "New file". There is no stat endpoint, so the check is a read that is expected to fail. `prompt()` to match New folder directly above it. Both deserve a real dialog and neither has one; making this one different would just be inconsistent. ── Verified rather than assumed ── `getActiveFile()` only matches ALREADY-OPEN files, so a path arriving in the URL could have landed on an empty editor — the exact silent failure this whole audit keeps turning up. It does not: CodeEditor.tsx:60-76 fetches and opens an unopened `?file=`, with an `unreadable` set guarding the retry loop. Confirmed /code-editor renders with `urlState`, without which the param is ignored entirely. The param is imported as `EDITOR_FILE_PARAM` rather than written as 'file' twice, so renaming it cannot leave this behind. tsgo clean, frontend builds, 808 pass / 7 fail unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
cc889a864c |
file browser: close the accidental gaps in the context menu
The audit split the menu's omissions in two. Three were deliberate — OCR, Transcribe and Extract Audio were removed in July because the task system does them better, and those stay gone. The rest were nobody's decision. This is the rest. ── One menu body instead of two ── `DropdownMenuItems` and `ContextMenuItems` were character-identical apart from the component prefix: 159 lines duplicated, including the same comment twice. Radix gives both families the same props, so the components are now a parameter and there is one list. That is why this diff removes more than it adds while adding seven items — and why the next item only has to be written once. ── Added to the row menu ── - Open — double-click was the only way. Every file manager puts it first. - Open in editor — `/code-editor` is on the SAME `files` permission as `/files`, so anyone who can browse could already edit; there was just no way to get there from a file. Narrower than Read Aloud on purpose: that one uses the `text` FALLBACK type, which matches .exe and .bin. - Paste into folder — a move was only expressible as cut → navigate → paste. Right-clicking the destination is the obvious gesture and did not exist. - Duplicate — one call away the whole time; `/copy` already resolves collisions to " (copy 2)". - Compress — the missing half of Extract. `/download` shelled out to zip but streamed the result away, so nothing could make an archive and keep it. New `POST /file-browser/compress` writes it beside the original. - Pin / Unpin — pinning existed only in the widget, which is not where you meet a file worth keeping to hand. ── Added to the background menu ── - Clone repository and Show/Hide hidden files. Both were toolbar-only, and the toolbar hides them under `md:` — so on a phone neither existed. All four desktop-only toolbar actions are now in this menu, which long-press reaches. - Paste is gated on the clipboard, as both toolbars already were. Ungated it fell through to the OS clipboard path and either toasted a secure-context error or silently did nothing — an item that looked available and was not. ── Removed ── `pcm-worklet-processor.js`, orphaned when cliamp left for the music plugin this morning. Verified unreferenced; the plugin ships its own copy inline. The `Play` hole itself is NOT closed and cannot be from here: there is no way for a plugin to register a context-menu item. Tasks and agents are the only extension mechanism and a task can only contribute a task entry. That is a platform gap and wants its own decision. Verified the zip invocation by hand for all three shapes — single file, directory (recursive, contents included), and a multi-item selection. Archive naming strips the extension only for a file, so a directory called `my.photos` stays `my.photos.zip` rather than becoming `my.zip`. tsgo clean, frontend builds, 808 pass / 7 fail unchanged. SelectionActions.tsx and usePipelineRunner.ts are prettier reflowing long lines — no semantic change, caught by formatting the folder. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
640529ccba |
offscale in the catalogue, and the comments the rename falsified
The plugin half is in gitea.officer.dev/plugins/offscale (95b84ea). This is what
the platform owed it.
- marketplace: offscale now ships assets/icon.png, so the catalogue carries an
iconUrl and a `bare` tile like music's. The lucide `icon` stays as the fallback
for a failed asset publish — a glyph beats the generic box.
- Four schema files cited `headscale_servers` as the shape they copied. The table
is `offscale_servers` as of today, so those sentences named a table that no
longer exists. Same for secret-store.ts's list of purposes.
The crypto purpose moved with it: `decryptSecret('headscale', …)` in the plugin
is now `'offscale'`, and the secret-store row was renamed rather than abandoned,
so the key material is preserved and the change is reversible. Safe only because
offscale_servers held 0 rows — one stored API key and this would have been a
re-encryption, not a rename.
Verified: offscale_servers, uq_offscale_servers_one_active and
uq_offscale_servers_user_url all exist in Postgres and nothing named headscale
does. Dropped the empty table by hand first, because drizzle-kit push treats a
rename as an interactive prompt and would have hung.
tsgo clean. 808 pass / 7 fail — +21 from offscale's first tests, same 7 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
dd26e4a688 |
example leaves too; plugins/ is documentation now
Done with `tea` as admin: plugins/offscale made public, plugins/example created public, both verified anonymously over https — which is the check that matters, because fetch.ts clones with no credentials and a private plugin simply cannot be installed from the marketplace. plugins/example 8 files, cloned back and diffed identical plugins/offscale now public (was private, so was uninstallable) `.gitignore` is one line now — `/plugins/*/`. The trailing slash is the whole design: it ignores DIRECTORIES, so files at the top of plugins/ stay tracked. The documentation about plugins belongs to the platform; the plugins do not. All three are in the marketplace catalogue, which is what makes this reversible: before this, untracking offscale meant a fresh install could never get it back. Now the store is the way in for all three. CatalogueEntry gains `icon` (a lucide name) alongside `iconUrl`. Both new entries ship glyphs rather than artwork, and without it they drew the generic puzzle piece in the store and their real icon after install — which reads as the icon changing rather than the store not knowing it. EXTRACTING-A-PLUGIN.md pointed at four directories a fresh checkout no longer has. It now gives repository URLs, says up front that this directory holds documentation rather than plugins, and carries a table of where each one went. Checked first that no tracked source statically imports a plugin directory — none does, so a fresh clone still builds. tsgo clean, frontend builds, 787 pass / 7 fail (unchanged). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
cca85a7524 |
offscale moves to its own repository
Pushed to gitea.officer.dev/plugins/offscale (50 files, verified byte-identical to the working copy by cloning it back), then untracked here. Order matters and it was this way round deliberately: until that push, this repository was the only copy of those 49 files. Untracking first would have left them on one disk. The push is what made the removal safe, so it happened first and was verified before anything was removed. The files stay on disk and the installed plugin keeps working — this changes who owns the code, not what is running. `example` stays tracked, alone. It has no repository yet, and it is the reference implementation EXTRACTING-A-PLUGIN.md sends people to read; removing it would both delete it from everywhere but this disk and leave the doc pointing at nothing. It follows once it has a remote. Not done, and worth knowing before a fresh install: plugins/offscale is PRIVATE, and fetch.ts clones anonymously over https with no credentials by design. So offscale cannot be installed from the marketplace the way music can. It needs to be public, or the marketplace needs authentication — which is a feature, not an oversight to patch quietly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |