6 Commits

Author SHA1 Message Date
cynarAI
2b967df569
fix(api): turn repositories found by the onboarding scan into real projects (#116)
The scan's project phase called prisma.space with fields the Space model
does not have (title, path). Both calls threw, a per-repository
try/catch swallowed the errors, and no project was ever created. With
the field names fixed, the space would still have had no organization
or membership, so nobody could have seen it.

The phase now goes through createSpaceForMember and
wireProjectWorkspace, the helpers behind spaces.create: each repository
becomes a project of the deployment owner in their current
organization, linked to its folder with its git remote, branch and
head. It still runs only in the owner's scan with ONBOARDING_SCAN_HOME
set. A repository whose real folder one of the owner's projects already
links is skipped, so scanning again creates nothing; the phase stops at
the per-member space limit; and a second start while a scan runs (a
StrictMode remount, a retry) joins it instead of linking everything
twice. Discovery no longer descends into dot folders, where shell and
editor plugin checkouts would otherwise become projects. The Prisma
client is typed, so a field the schema lacks is a compile error again
instead of a swallowed one.

readGitCheckout loaded child_process with require(), which does not
exist in the ES module runtime the API runs in, so linking any folder
with a .git directory threw "require is not defined", in the scan and
in the New project dialog alike. It now imports spawn statically; the
module is only reachable through its server-only subpath, so browser
bundles still never load it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ebcq9seT9eCoHtqxuWEUzg
2026-10-03 18:22:10 +02:00
cynarAI
4c619b25b9
fix(api): keep the onboarding scan off the host unless the owner opts in (#98)
* fix(api): keep the onboarding scan off the host unless the owner opts in

The first-run scan walked the home directory of the API process user for
every account that signed up, with no consent, and its status endpoint
accepted any scan id. Any account could read the repository paths and
remotes of the server owner.

The scan now stays simulated unless the deployment configures
ONBOARDING_SCAN_HOME and the requesting account is the deployment owner;
the previous HOME fallback is gone. Scan records remember who started
them and the status endpoint answers only that account.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u

* ci: give each runner on a shared host its own E2E ports

Two Linux runners live on the same host. Every Web E2E job first frees
"stale" listeners on the fixed ports 3110, 3111, 5180 and 4321 with
fuser -k, so a job starting on the second runner killed the Vite server
of the job already running on the first one. The victim died with
SIGKILL (exit 137), and its remaining tests failed on reloads that could
no longer reach a server. This is what made the Web E2E run on this PR
red, and it explains the recurring reload failures on main whenever two
runs overlapped.

The workflow now derives API_PORT, WEB_PORT and WWW_PORT from the runner
name (suffix -N means an offset of N times 100), and the port-freeing
script follows those settings instead of a hard-coded list. The harness,
Vite, the API and the marketing site already read these variables.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
(cherry picked from commit 2f05ab6a817e5198e2a740706976108b7b1edde1)

* test(testkit): cover the env-driven E2E ports instead of a fixed list

The ports test parsed a hard-coded array that no longer exists. It now
runs the script on a fake host whose fuser finds nothing, and checks the
default ports, the per-runner override, the rejection of a non-numeric
setting, and that the workflow picks the ports before freeing them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
(cherry picked from commit cd0aedafcdec1b24dea924d8924b3b29af29d598)

* ci: keep every runner off the default E2E ports

Branches that still free the fixed ports 3110, 3111, 5180 and 4321 keep
running on the shared host (main, the nightly run, other open PRs) until
they carry the per-runner ports. A job of ours on the runner without a
numeric suffix used exactly those defaults, so such a neighbour could
still kill it, and its own port freeing could kill the neighbour. The
unsuffixed runner now starts at offset 100, so no job from this workflow
touches the defaults in either direction.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
(cherry picked from commit ddf5febdb3072425442ef375ca0be63fbe09e7f1)

* fix(web): recover lazy routes and overlays from a failed module fetch

When the browser aborts a module request while a page loads, the lazy
import rejects and the route throws, leaving a blank page. Chromium does
this whenever a network interface appears or disappears mid-request
(net::ERR_NETWORK_CHANGED), which happens on a laptop that changes
networks and on the CI host every time a container starts or stops. A
Web E2E run hit exactly this: two modules of the onboarding page failed
to load and the suite waited on an empty document.

Lazy routes and overlays now load through a helper that retries the
import once and, when the browser keeps rejecting it from its module
map, reloads the page a single time before surfacing the error.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
(cherry picked from commit d5dacb12f14380071ef14ba8845d18c9d39e3fac)

* fix(web): reload once when the module graph is aborted while booting

The lazy-route recovery cannot help when the browser aborts a module of
the static import graph: nothing of the app runs, the root stays empty,
and the only trace is a console error. A Web E2E run hit this right
after a page reload, when four modules of the shell failed with
net::ERR_NETWORK_CHANGED and the shell never rendered.

An inline script in the HTML entry now listens for the error event of
the module script and reloads the page once, guarded by a session flag
that the entry module clears after a successful boot. The existing
preload recovery stays in place; it only covers Vite's chunk preloads of
production builds.

A new E2E spec aborts one module request during boot and one lazy route
request, and expects the sign-in page to render in both cases.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MRtGG9ARfqqhma3t85Ro2u
(cherry picked from commit e5b7e036e1a60e7e270592c4b9382ee23ed45ccb)

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>
2026-10-02 21:48:46 +02:00
cynarAI
5426bb73c5 fix(e2e): wait for shell-ready after RPC bot create (#87)
* fix(e2e): wait for shell-ready after RPC bot create

createNamedBot now waits for data-ready and the Message composer after
navigating to a freshly created bot, instead of asserting immediately on
a cold page load where bootstrap had not finished.

Also fix onboarding scan advancing to bot creation (onComplete was a no-op)
and use a fast simulated scan when AGENT_RUNTIME=scripted so CI E2E does
not walk the real filesystem during onboarding.

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

* style: apply biome format to touched onboarding files

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

* style: clear biome lint in onboarding scan files touched by the fix

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

* style: format onboarding-scan after rebase onto main

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

* style: fix biome lint on main files blocking Product CI

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

* fix(onboarding): allow scan before first bot exists

The scan RPC required a non-empty botId, but onboarding runs scan before
Chief is created and the UI sent an empty string. That rejected the RPC,
left the flow on /onboarding, and every completeOnboarding helper timed out.

Make botId optional, omit it from the client when unknown, advance to bot
creation when scan completes, and keep scripted/fake runs on the fast scan path.

Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>

---------

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: cynarAI <cynarAI@users.noreply.github.com>
2026-09-24 03:38:40 +02:00
c18a04ce3f feat(api): sub-agent roles + DB project creation in onboarding scan
- Auto-generate specialist roles from detected interests/skills:
  Code Engineer, UI/UX Designer, Data Analyst, DevOps, Music, Writer
- Always include General Assistant role
- Embed role descriptions + instructions in agent briefing
- Create real Prisma Space entries for discovered git repos
- Deduplicate: skip spaces that already exist
- Pass prisma client through scan pipeline chain

Co-Authored-By: Claude Code <noreply@anthropic.com>
2026-09-24 00:17:29 +00:00
85a0f3860a feat(api): real onboarding scan — filesystem, Git repos, profile compilation
- Replace simulated scan with real filesystem scan of home directory
- Discover Git repositories via .git directory scanning
- Analyze repos: remote URLs, branches, last commits, language stats
- Compile user profile from file types, languages, and repo data
- Generate agent briefing with tech stack, interests, and skills
- Create project folders from discovered Git repositories
- 1500+ line implementation with comprehensive file classification
2026-09-23 23:43:51 +00:00
20afcb0d0b feat: security headers + onboarding scan & profile creation flow
Security:
- Add CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy,
  Permissions-Policy as Hono middleware (after CORS)
- CORS already hardened via isTrustedOrigin (localhost, private, Tailscale)

Onboarding scan flow:
- New 'scan' step between 'integrations' and 'bot' in onboarding
- OnboardingScanProgress.tsx: progress UI with 4 phases (scanning, connecting,
  building, briefing) with real-time polling
- onboarding-scan.ts: backend scan pipeline (in-memory registry, async phases)
- RPC routes: onboarding.scan + onboarding.scanStatus
- Contracts updated with new procedure definitions

Co-Authored-By: Claude Code <noreply@anthropic.com>
2026-09-23 23:31:12 +00:00