mirror of
https://github.com/awizemann/scarf.git
synced 2026-05-10 10:36:35 +00:00
32713915062a72fbfefc06d2c8fb5dfc39b6982b
344 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Alan Wizemann
|
742605d359 |
M7 #3: Chat 'Connecting…' overlay during SSH exec handshake
ChatController already transitioned through a `.connecting` state between tap-Chat and first-message-ready (ACP initialize + session/new take ~0.5–1.5 s on a warm network), but there was no visible UI — the screen stayed on the idle layout with a disabled composer. Users interpreted the silence as a frozen app (pass-1 M7 #3). Adds a `.regularMaterial` overlay with a large ProgressView + "Connecting to <nickname>…" text, rendered whenever `controller.state == .connecting`. Disappears automatically when state flips to `.ready` (normal path) or `.failed` (handoff to the existing errorOverlay). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
fee5e72d30 |
M7 #12: rename Disconnect -> Forget this server + confirmation
Pass-1 found that "Disconnect" was actually a factory reset — wiping both Keychain SSH key and UserDefaults config, forcing full re-onboarding (including re-generating a key and appending it to authorized_keys on the remote). Interim fix ahead of M9 multi-server work: - Relabel button "Forget this server". - Keep destructive role. - Gate tap on a confirmationDialog so users see exactly what gets wiped and can back out. - Add a footer explaining the authorized_keys consequence so the user isn't surprised by a failed reconnect later. Behaviour is unchanged (still wipes both stores). M9 introduces the proper split: soft Disconnect (closes live transport, keeps credentials) vs. hard Forget (this behaviour). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
f41ac1c84e |
M7: pass-1 quickfixes (PATH, SFTP tilde, SOUL.md, ScarfGo bundle id)
Four fixes surfaced during the 2026-04-24 pass-1 smoke test of the iOS companion against a local Hermes host. All discovered while collaboratively driving the Simulator + tailing os.Logger. 1. ACPClient+iOS.swift — ACP exec command prepends common install paths to PATH. SSH RFC 4254 exec uses a non-interactive shell whose PATH is sshd's default (`/usr/bin:/bin:/usr/sbin:/sbin`); `.zshrc` doesn't source, so `~/.local/bin/hermes` (pipx default) was invisible and the agent died with "command not found: hermes". Mirrors HermesPathSet.hermesBinaryCandidates (the Mac-side local probe list) inline in the exec command. 2. CitadelServerTransport.swift — SFTP tilde expansion. Every Memory/Cron/Skills/Settings read used paths like `~/.hermes/memories/MEMORY.md`. SFTP treats `~` as a literal character, not a home-dir alias — so every read silently returned nil and the UIs showed "empty file" instead of the real content. Added a per-connection cached `resolveHome()` + a `resolveSFTPPath` helper applied to every SFTP entry point (readFile / writeFile / fileExists / stat / listDirectory / createDirectory / removeFile). This was the single biggest blocker on pass-1. 3. IOSMemoryViewModel.swift + MemoryListView.swift — SOUL.md added as a third Memory row. SOUL.md lives in the Personalities feature on Mac; folding it into Memory on iOS matches the on-the-go scope (all agent prompt inputs in one place). Uses the existing `HermesPathSet.soulMD` path; no new plumbing. 4. project.pbxproj — bundle id rename for ScarfGo branding: - CFBundleDisplayName: "Scarf Mobile" -> "ScarfGo" - PRODUCT_BUNDLE_IDENTIFIER: com.scarf-mobile.app -> com.scarfgo.app Xcode target name stays "scarf mobile" internally (rename surgery isn't worth the PBX churn). Home-screen label + bundle id now match the product name. Both schemes build green. Phase 1 starter commit — per-item M7 fixes follow in subsequent commits. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
19b4ba9995 |
Merge branch 'main' into scarf-mobile-development (v2.3.0)
Brings the iOS companion branch current with main's v2.2.0, v2.2.1,
and v2.3.0 landings — templates + configuration + catalog (v2.2),
projects folder hierarchy + per-project Sessions sidecar + AGENTS.md
context block + Tool Gateway + Nous Portal OAuth + hermes dashboard
webview (v2.3), and credential-pool OAuth expiry + Nous agent-key
rotation (post-v2.3).
Resolutions:
- ScarfCore Models (HermesConfig, ProjectDashboard, HermesPathSet) —
forward-ported Tool Gateway's platformToolsets, project-registry v2
folder/archived fields, and sessionProjectMap path into the moved
ScarfCore copies. Deleted the old Mac-target paths.
- ScarfCore ModelCatalogService — merged main's overlay-only provider
support (Nous Portal + OpenAI Codex + Qwen OAuth + …) so iOS and
macOS pickers see the same provider list. Widened HermesProviderInfo
/ HermesProviderOverlay APIs to public.
- ScarfCore ProjectsViewModel — layered main's v2.3 registry verbs
(moveProject / renameProject / archive / unarchive / folders) onto
the M0d-extracted VM, keeping public surface for the Mac target.
- ScarfCore ConnectionStatusViewModel / RichChatViewModel — widened
`private(set)` to `public private(set)` so Mac views can read
status, lastSuccess, acp*Tokens, originSessionId, acpCommands,
quickCommands.
- ScarfCore HermesConfig+YAML — added platform_toolsets parsing to
the iOS YAML path so config.yaml round-trips the same as macOS.
- RichChatViewModel quick-commands — inlined the Mac-target's
QuickCommandsViewModel.loadQuickCommands into ScarfCore using the
existing HermesYAML parser, removing the cross-module dependency.
- HealthViewModel — took main's Tool Gateway + hermes-dashboard
webview sections wholesale; file stays macOS-only.
- ChatView auto-merge — confirmed resume-session fix (
|
||
|
Alan Wizemann
|
05e2a8444a |
feat(credential-pools): surface OAuth expiry + Nous agent-key rotation
auth.json entries now carry expires_at_ms / expires_at and (for Nous) agent_key_obtained_at. Decode the new fields, add an expiryBadge helper, and render a red "expired" / orange "expires in Nd" pill when a credential is past or within 7 days of expiring. Nous entries also get a muted "agent key · Nh ago" line so manual rotations are visibly confirmed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
fe104b83fa |
feat(health): surface hermes dashboard web UI in Health
Hermes v0.10.x ships a local web dashboard launchable via `hermes dashboard` on port 9119. Scarf now detects it via a 3s `/api/status` probe and offers Launch / Stop / Open-in-Browser controls on the Health tab. Local contexts only — the dashboard binds 127.0.0.1 and remote tunneling is deferred. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
5498a08b11 | chore: Bump version to 2.3.0 v2.3.0 | ||
|
Alan Wizemann
|
a864c9af02 | chore(l10n): Xcode auto-extracted new Tool Gateway strings | ||
|
Alan Wizemann
|
ec506d4652 |
docs(v2.3): add Tool Gateway + Nous Portal sign-in to release notes + README
v2.3 now lands two themes together: Projects Grow Up (existing) and Hermes v0.10.0 Tool Gateway support (new, just merged on the feature branch). The release notes and the repo README's "What's New" section are updated to reflect both. Release notes: - Headline intro rewritten to frame both themes as the v2.3 story. - New "Tool Gateway — Nous Portal support" section between "Icon tweak" and "Migrating from 2.2.x": picker overlay merge surfacing 6 previously-invisible providers, in-app device-code sign-in sheet, per-task Nous routing in the Auxiliary tab, Health card, Credential Pools dead-end fix + auth-type gating, Messaging Gateway rename. - "Under the hood" gains the Tool Gateway services paragraph (NousSubscriptionService, NousAuthFlow, NousSignInSheet, CredentialPoolsOAuthGate) + the PYTHONUNBUFFERED=1 subprocess-env fix note. Test count bumped from 93 → 120 (14 new tests in ToolGatewayTests, NousAuthFlowParserTests, CredentialPoolsGatingTests). - "Migrating from 2.2.x" gains a Hermes version paragraph spelling out that v0.10.0 is required for the Tool Gateway features (rest of 2.3 works on earlier Hermes, just without Nous in the picker or subscription data in Health). - "Documentation" section lists the new Hermes Version Compatibility + Core Services wiki updates that accompany this release. README: - v2.3 "What's New" bullet list gains a Tool Gateway bullet positioned between the chat-indicator bullet and the window-layout bullet. - Trailing "See the full release notes" line expanded to reference the Hermes Version Compatibility wiki page so users on Hermes v0.9 know why they don't see Nous in their picker. Companion wiki update already pushed in 741b253 on the wiki repo (Hermes-Version-Compatibility, Core-Services, Home). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
38226fea2c |
fix(nous): force PYTHONUNBUFFERED=1 so device-code output surfaces
The sign-in sheet was stuck on the "Contacting Nous Portal…" spinner
even though hermes was running correctly. Root cause: Python
block-buffers stdout when it's a pipe instead of a TTY, and
`hermes auth add nous` enters a 15-minute polling loop after printing
the device-code block without ever calling `input()` — so nothing
flushes the buffer. Our readability handler never receives the URL +
user_code lines.
PKCE doesn't hit this because hermes calls `input("Authorization
code: ")`, which flushes stdout before blocking. Device-code has no
equivalent trigger.
Setting PYTHONUNBUFFERED=1 in the subprocess environment forces
line-buffered stdout for the duration of the flow — the device-code
block surfaces immediately, our regex extracts the URL and code, and
the sheet transitions into the waitingForApproval state as intended.
Local-only fix; remote SSH contexts get the remote's login env
untouched (the user's remote shell config owns buffering behavior
there).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
257772e2d1 |
feat(nous): in-app sign-in + credential pools auth-type gating
The Tool Gateway feature shipped the Nous Portal provider in Scarf's
picker, a subscription-state detector, and a per-task aux toggle — but
there was no way to actually sign in. `hermes auth` in a terminal took
six steps, and Credential Pools' "Start OAuth" button silently stalled
for `nous` because it tried to run the PKCE flow against a device-code
provider.
Changes:
- NousAuthFlow: new @Observable MainActor service that spawns
`hermes auth add nous --no-browser`, parses the device-code block
(verification_uri_complete + user_code) with two line-anchored
regexes, opens the verification URL via NSWorkspace.shared.open,
and confirms success by re-reading auth.json via
NousSubscriptionService. Detects the `subscription_required`
failure and extracts the billing URL so the UI can offer a
Subscribe link.
- NousSignInSheet: four-state sheet (starting / waitingForApproval /
success / failure). Shows the user code in a large monospaced
badge with Copy + re-open-browser affordances, auto-dismisses
1.2s after success, Subscribe + Try again + Copy error buttons
on failure.
- Wired three entry points (per user-approved plan):
1. ModelPickerSheet's Nous Portal subscription summary — replaces
the stale "Run hermes auth" caption with a primary
"Sign in to Nous Portal" button.
2. AuxiliaryTab's per-task Nous toggle — inline "Sign in first"
button when not subscribed, instead of a dead-end caption.
3. Credential Pools "Add Credential" sheet — when provider is
`nous`, replaces the broken Start OAuth button with
"Sign in to Nous Portal".
- CredentialPoolsOAuthGate: testable helper that routes provider IDs
to the right OAuth flow based on the overlay table. Closes the
silent-fail dead-end for openai-codex, qwen-oauth,
google-gemini-cli, and copilot-acp too — disables the generic
button with an inline "run hermes auth add <provider> in a
terminal" hint. PKCE providers (anthropic, etc.) and unknown
providers still pass through as `.ok` — this gate is strictly
additive.
Tests: 14 new tests across two suites (NousAuthFlowParserTests,
CredentialPoolsGatingTests). Full suite 120/120 green on top of
v2.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
115bc16b14 |
feat: Nous Portal + Tool Gateway support for Hermes v0.10.0
Hermes v0.10.0 (v2026.4.16) introduces the Tool Gateway — paid Nous Portal subscribers route web search, image generation, TTS, and browser automation through their subscription without separate API keys. - ModelCatalogService merges HERMES_OVERLAYS on top of the models.dev cache, surfacing 6 overlay-only providers (Nous Portal, OpenAI Codex, Qwen OAuth, Google Gemini CLI, GitHub Copilot ACP, Arcee) that were previously invisible in Scarf's picker. Subscription-gated providers sort first. - NousSubscriptionService reads ~/.hermes/auth.json -> providers.nous to detect subscription state. Read-only; Hermes owns the write path. - ModelPickerSheet renders a "Subscription" pill, auth-type-aware instructions, and free-form model-ID entry for overlay providers (no models.dev catalog for them). - AuxiliaryTab gains a per-task "Nous Portal" toggle that flips auxiliary.<task>.provider between "nous" and "auto". Hermes derives gateway routing from provider selection; there's no separate use_gateway key in the source. - HermesConfig + HermesFileService parse platform_toolsets. - HealthViewModel adds a synthetic "Tool Gateway" section showing subscription state, platform_toolsets, and which aux tasks are routed through Nous. - Gateway -> Messaging Gateway rename (sidebar, dashboard card, menu bar, log-source filter, Settings/Agent/Gateway section header) to disambiguate from the new Tool Gateway. - CLAUDE.md bumped to Hermes v0.10.0 (v2026.4.16) with a keep-overlayOnlyProviders-in-sync reminder. - 13 new tests covering overlay merge, subscription detection, and platform_toolsets parsing; full suite (106 tests, 19 suites) green on top of v2.3 projects branch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
eda5e467f9 |
Merge branch 'v2.3-projects': v2.3 — Projects Grow Up
Brings in 17 commits delivering the full v2.3 scope: - Projects sidebar hierarchy: folders, rename, archive/unarchive, fuzzy search (⌘F), ⌘1–⌘9 keyboard jumps. Registry schema v2 (optional folder + archived fields); backward-compatible with v2.2.1 readers. - Per-project Sessions tab alongside Dashboard / Site. "New Chat" spawns hermes acp with the project's directory as cwd and attributes the resulting session via a Scarf-owned sidecar at ~/.hermes/scarf/session_project_map.json (Hermes's state.db has no cwd column, so Scarf owns the mapping). - Agent context injection: ProjectAgentContextService writes a Scarf-managed block into <project>/AGENTS.md between <!-- scarf-project:begin/end --> markers. Hermes auto-reads AGENTS.md at session boot, so the agent now actually knows the project name, dashboard path, template id, configuration field NAMES (secret-safe — never values), registered cron jobs, and uninstall-manifest presence. Template-author content outside the markers is preserved byte-identical across refreshes. - Chat indicator: folder chip in SessionInfoBar + "Chat · <ProjectName>" nav title when scoped. Resumed project- attributed sessions automatically re-surface the indicator via the attribution lookup at resume time. - Window-layout cleanup: .windowResizability(.contentMinSize) + idealHeight caps on Chat/Sessions subtrees so the window stops growing past the screen when switching to content-heavy sections. Pre-existing issue surfaced by the new per-project surfaces. 22 new Swift tests across ProjectRegistryMigrationTests (7), ProjectsViewModelTests (7), SessionAttributionServiceTests (7), and ProjectAgentContextServiceTests (13) — total suite size is now 93/93. Release notes at releases/v2.3.0/RELEASE_NOTES.md (9.4 KB). README "What's New in 2.3" block prepended; prior v2.2 block demoted to "Previously, in 2.2." Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
9127aef682 |
docs: v2.3.0 release notes + README What's New
Prep commit for the v2.3 release. Covers the 16 feature + fix commits landed on the v2.3-projects branch: - releases/v2.3.0/RELEASE_NOTES.md — new file. release.sh picks this up automatically as the GitHub release body at tag time. Sections: sidebar grows up (folders/rename/archive/search/ keyboard jumps), per-project Sessions tab + sidecar, the AGENTS.md marker-block injection (with the invariants — secret-safe, idempotent, bounded, non-fatal, bare-project friendly — called out explicitly), chat-UI project awareness (folder chip + nav title), window-layout cleanup, under-the- hood (new services, 22 new tests), migration, thanks. - README.md — "What's New in 2.3" block at the top; demotes the prior 2.2 block to "Previously, in 2.2" (condensed to the four most user-facing points since the full 2.2 notes live at the release link). - Localizable.xcstrings — Xcode auto-regen from the new string literals introduced across the v2.3 feature commits (folder chip tooltip, Sessions tab header, etc.). Riding along. 93/93 Swift tests still pass. No code change here — pure docs. Wiki Home + Release-Notes-Index updates land as a separate wiki commit after the release is cut (standard post-release chore per CLAUDE.md). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
5ae8db25c3 |
fix(chat): resume session on coordinator.selectedSessionId, not just pendingProjectChat
Clicking a session in the Projects Sessions tab routed to the Chat section (correct — we want interactive resume, not the read-only Sessions browser), but the session didn't actually load and the project chip didn't appear. Root cause: ChatView only observed `coordinator.pendingProjectChat` (for new chats), not `selectedSessionId` (for resumes). Setting the id had no effect because no consumer existed on the Chat side. Every other session-click site in Scarf routes to `.sessions`, and SessionsView consumes selectedSessionId at its `.task` + clears it. Projects is the exception — the whole point of the per-project Sessions tab is to resume chats interactively rather than browse them, so we route to `.chat`. That routing was right; the Chat side just needed to grow the symmetrical consumer. This commit adds two handoff paths in ChatView (mirrors the existing `pendingProjectChat` pattern): - `.task` picks up a selectedSessionId that was set before ChatView mounted (cold-launch handoff from Projects). - `.onChange(of: coord.selectedSessionId)` picks up mid-session navigation (user clicks a session while already in Chat). Both call `viewModel.resumeSession(id)` then clear the coordinator field. The project chip rendering + navTitle update then happen automatically inside ChatViewModel.resumeSession -> startACPSession, which already looks up attribution via SessionAttributionService.projectPath(for: resolvedSessionId) — that plumbing was in from Part B. The bug was entirely in the trigger, not the side-effect. `else if` between pendingProjectChat and selectedSessionId makes precedence explicit — new-chat wins over resume if both are somehow set. In practice only one is ever populated per navigation, but the explicit ordering avoids surprise. No race with SessionsView's own consumer: `coordinator.selectedSection` ensures only one view is rendering at a time, and both consumers clear the field on consume. 93/93 Swift tests still pass. No test change — this is a view- wiring integration fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
fb833d4a0a |
fix(projects): open HermesDataService before filtering sessions
Sessions tab was showing "This project has N attributed sessions,
but none are in the recent history. They may have been deleted
from Hermes." on projects with valid sidecar entries and actual
sessions present in state.db. Root cause: the VM never opened
the DB handle.
`HermesDataService` is an actor with a lazily-initialised SQLite
pointer. Every query method short-circuits to `[]` when
`db == nil`. Callers have to open/refresh the handle explicitly
— InsightsViewModel does it (line 106), ActivityViewModel does
it (line 60). ProjectSessionsViewModel was constructed fresh
per project, never inherited a shared service, and never called
refresh() itself, so fetchSessions returned empty on every load
and the filter against the (correctly-populated) sidecar map
produced zero matches. The empty-state message ("may have been
deleted") fired on that false-negative.
The data was fine all along: sqlite3 ~/.hermes/state.db confirmed
both attributed sessions with source='acp', parent_session_id
IS NULL — they pass fetchSessions's WHERE clause cleanly. The
sidecar mappings were correct. The file watcher was firing. The
only missing piece was the DB-open precondition.
Fix: `_ = await dataService.refresh()` before fetchSessions,
mirroring the pattern used by every other feature VM that
consumes HermesDataService. Also adds a `close()` on the VM + an
onDisappear handler on the view, so the handle doesn't dangle
once the tab isn't visible — same cleanup ActivityView has.
This is NOT forward-only. Existing sidecar entries that
currently show the misleading empty-state will surface
correctly as soon as users rebuild — no data migration, no
re-create-the-chat, no backfill. The bug was "couldn't read what
was already there," not "lost old data."
93/93 Swift tests still pass. No test change — the fix is an
integration-level call-ordering detail that isn't meaningfully
testable without mocking HermesDataService (overkill for a
two-line fix).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
7656ad8052 |
docs(v2.3): document how agents see Scarf projects
Three doc updates covering the AGENTS.md context-injection pattern introduced in the previous commit. CLAUDE.md — new "Project-scoped chat + Scarf-managed AGENTS.md context (v2.3)" subsection under Project Templates. Covers: - The session-project sidecar at ~/.hermes/scarf/session_project_map.json (why it exists, what manages it) - How Hermes picks up project context: cwd-based auto-load of the first matching context file (priority order, 20KB cap) - Exact marker format and block shape - Invariants that future edits must preserve: secret-safe, idempotent, bounded-region, non-fatal, refresh-before-session-start ordering - Template-author contract: leave the region alone, put instructions below - Known caveat: parent-directory `.hermes.md` shadowing (deferred to v2.4) scarf-template-author SKILL.md — new pitfall bullet in the "Common pitfalls" checklist telling scaffolding agents to preserve the `<!-- scarf-project -->` region and put template- specific instructions below it. Rebuilt the bundle so installs from the catalog pick up the guidance; regenerated catalog.json. Wiki update (Project-Templates page) lands next via scripts/wiki.sh. 93/93 Swift + 24/24 Python tests pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
5b1481f33f |
feat(projects): Scarf-managed project-context block in AGENTS.md
Hermes has no native "project" concept and the ACP wire protocol drops extra params at `session/new`. But Hermes DOES auto-read AGENTS.md from the session's cwd at startup (research confirmed: priority order `.hermes.md` → `HERMES.md` → AGENTS.md → CLAUDE.md → .cursorrules; 20KB cap; first match wins). So the agent- awareness path is file-based, not protocol-based. This commit adds `ProjectAgentContextService` — a one-job service that writes a Scarf-managed block into `<project>/AGENTS.md` between `<!-- scarf-project:begin -->` and `<!-- scarf-project:end -->` markers. Same pattern as the v2.2 memory-block appendix: bounded, self-declaring, re-generable, safe on hand-authored content outside the markers. ## Block contents - Project name (from registry) - Project directory path - Dashboard.json path - Template id + version (when template-installed) - Configuration field NAMES with type hints — never VALUES. Secrets always render as `field_key (secret — name only, value stored in Keychain)`. Config.json values never appear in the block, so the injected context is safe to drop into any agent regardless of what's in Keychain. - Registered cron jobs attributed to this project (matched via the `[tmpl:<id>] …` prefix convention) - Uninstall manifest reference (when `.scarf/template.lock.json` exists) - A note to the agent: cwd is the project dir, respect template content below the block. ## Integration point `ChatViewModel.startACPSession(resume:projectPath:)` refreshes the block BEFORE `client.start()` — Hermes reads AGENTS.md during session boot, so it has to land on disk first. `try?` with a warning log: a failed refresh doesn't block the chat, the session just starts without the extra context. ## Idempotency + safety - Two consecutive refreshes produce byte-identical output - Hand-edits outside the markers survive every refresh - Empty project dir → AGENTS.md created with just the block - Existing AGENTS.md without markers → block prepended; rest preserved below - Orphaned begin-marker (no end) → treated as "no block present," new block prepended, orphan left in place (likely hand-typed, not a Scarf corruption) ## Tests 13 new tests in ProjectAgentContextServiceTests: - applyBlock pure-text transform: prepend / replace / idempotency / empty input / orphaned-marker fallback - renderBlock content: identity fields, template presence, config field names (and CRITICALLY: no values leak for secret fields) - refresh end-to-end on isolated temp dirs: file creation, user content preservation, idempotency across runs, stale-block rewrite 93/93 Swift tests pass (was 80; +13 new). ## Deferred TERMINAL_CWD env-var plumbing in ACPClient was scoped in the plan but skipped — ACPClient.start() doesn't know the cwd at launch (it's per-session), and plumbing it would restructure the actor's lifecycle. Hermes already receives the cwd via ACP's `session/new` params and uses it for context-file discovery there, so TERMINAL_CWD is belt-and-suspenders we can add later without breaking anything. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
e4920538d2 |
feat(chat): show active-project indicator in SessionInfoBar + nav title
Adds a visible cue telling the user when their chat is scoped to a Scarf project. Two surfaces: - **SessionInfoBar** gets a folder-fill icon + project name chip at the start of the bar (before the working dot + title). Rendered with `.tint` foregroundStyle so it's visually anchored as the first piece of context. Hidden for non-project chats — the bar looks identical to v2.2.1 when projectName is nil. - **Navigation title** becomes `Chat · <ProjectName>` when scoped, stays as plain `Chat` otherwise. Matches macOS conventions for "subject — detail" titles. ChatViewModel gains two `@Observable` properties: - `currentProjectPath: String?` — absolute path, source of truth for attribution lookups - `currentProjectName: String?` — resolved via the projects registry at session-start; stored to avoid disk reads on every render. Falls back to the raw path (rather than nil) when a session's attribution points at a project no longer in the registry — the user still sees *something* rather than silently losing the indicator. Both are populated in `startACPSession(resume:projectPath:)` from two sources: 1. If the caller passed `projectPath` — fresh project-chat case 2. Otherwise, SessionAttributionService.projectPath(for: resolvedSessionId) — resumed-session case. Means clicking an old project-attributed session from ANY surface (the project's Sessions tab, the global Resume menu) re-surfaces the indicator. When the user starts a non-project session, both fields reset to nil explicitly so the indicator doesn't leak between chats. Files: - ChatViewModel.swift — new properties + resolve logic - SessionInfoBar.swift — new `projectName: String?` parameter + chip rendering - RichChatView.swift — passes chatViewModel.currentProjectName through to SessionInfoBar - ChatView.swift — navTitle reflects the active project 80/80 Swift tests still pass. Visual change only; no test change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
5340e70dd3 |
fix(projects): watch session-project-map so Sessions tab refreshes
ProjectSessionsView's `.onChange(of: fileWatcher.lastChangeDate)` was silently never firing when a new chat attributed a session to a project — the sidecar was written correctly, the session was in state.db correctly, attribution IDs matched exactly, but the per- project Sessions list didn't auto-refresh. Root cause: HermesFileWatcher.watchedCorePaths was missing `paths.sessionProjectMap` (`~/.hermes/scarf/session_project_map.json`, introduced in the v2.3 feature commit). Since the watcher didn't observe that file, writes from SessionAttributionService.persist produced no `lastChangeDate` change, the VM's onChange never ran, and the Sessions tab stayed empty until the user navigated away and back (triggering .task(id: project.id) to re-fire). One-line fix: add the sidecar to the watched-paths array. Now the flow works end-to-end: 1. User clicks "New Chat" on a project 2. ChatViewModel starts ACP session with cwd=project.path 3. SessionAttributionService.attribute writes the sidecar 4. HermesFileWatcher detects the change, bumps lastChangeDate 5. ProjectSessionsView's onChange fires, VM reloads, new session appears in the list immediately 80/80 tests still pass. No test change needed — the sidecar's direct tests are in SessionAttributionServiceTests; this is a file-watching integration fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
7ad78a5492 |
fix(layout): cap RichChatView/ProjectSessions idealHeight; revert broken detail wrap
Prior commits tried to solve the "window grows whenever Chat or
Sessions is selected" bug by wrapping NavigationSplitView's detail
slot with an explicit frame (`205bb2c`). That broke the HSplitView
layout in Projects — the project list column, dashboard header,
tab bar, and Sessions-tab header all vanished. Scarf's convention
(PlatformsView.swift:12 calls it out explicitly) is to apply
size constraints on individual HSplitView columns, never on an
outer wrapper.
This commit:
- Reverts the broken ContentView.swift outer frame from `205bb2c`.
NavigationSplitView.detail goes back to its v2.2.1 shape.
- Caps the subtrees whose natural ideal heights are what was
actually pushing the window past the screen:
- RichChatView: `.frame(minHeight: 0, idealHeight: 500, maxHeight: .infinity)`
on the outer VStack. The message list uses a plain VStack
(deliberately, to dodge the LazyVStack whitespace bug — see
RichChatMessageList.swift:13-24), so its natural ideal grows
with every message. Capping idealHeight at 500 gives the
window a screen-safe starting size without limiting how tall
the view can flex when the user drags the window bigger.
- ProjectSessionsView: same treatment with `idealHeight: 400`.
Replaces the earlier `.frame(maxWidth: .infinity, maxHeight:
.infinity)` which set MAX but didn't influence what got
reported upward as ideal.
- Xcode regenerated Localizable.xcstrings during builds; riding
along.
`.frame(idealHeight:)` is the specific SwiftUI knob that overrides
a child's reported ideal on the way up — `maxHeight: .infinity`
alone doesn't. With `.windowResizability(.contentMinSize)` (still
in scarfApp, left alone), the window sizes itself to the reported
ideal on open and respects user drags above the content min. With
a screen-safe ideal, the window opens at a usable size and never
pushes past the desktop.
User-verified: window behaves correctly across section switches,
resize persists, chat input bar always visible.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
205bb2c56e |
fix(window): pin detail column's reported frame so Chat/Sessions stop resizing window
Prior fixes ( |
||
|
Alan Wizemann
|
d9688781ee |
fix(app): windowResizability(.contentMinSize) so window stops auto-resizing
Root cause of the "window grows whenever I switch to Chat / the v2.3 Sessions tab" bug. Prior commits ( |
||
|
Alan Wizemann
|
9aad9051c4 |
fix(chat,projects): clamp detail-column views so they don't grow the window
Two sibling fixes to the one landed in |
||
|
Alan Wizemann
|
4baa3d4d28 |
fix(projects): clamp Sessions tab height so it doesn't push the window
The new Sessions tab's outer VStack had no maxHeight constraint.
Its inner `List(sessions) { … }` uses intrinsic content size — which
grows with the row count — and with enough sessions the enclosing
VStack would push the project window past the bottom of the screen.
Fixed by adding `.frame(maxWidth: .infinity, maxHeight: .infinity)`
to the outer VStack in `ProjectSessionsView.body`, matching the
pattern `siteTab` uses for its webview. Now the List fills the
available tab area and scrolls internally as expected.
Other v2.3 tabs already self-constrain (`widgetsTab` via ScrollView,
`siteTab` via explicit maxHeight). This brings Sessions in line.
80/80 Swift tests still pass. Visual-only fix; no test change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
799cdb19e1 |
feat(projects): per-project Sessions tab + sidecar attribution
Third and final v2.3 commit. Adds the Sessions tab alongside Dashboard and Site, and introduces the attribution sidecar that makes per-project session filtering possible without any upstream Hermes change. ## Sidecar Hermes's state.db has no cwd column on sessions — the cwd passed to `hermes acp` at session create is ephemeral from its side. Scarf now records session_id → project_path in ~/.hermes/scarf/session_project_map.json, owned end-to-end by Scarf. Written atomically on session creation; read by the per- project Sessions tab. Missing file = empty map; corrupt file = empty map (logged warning, no crash). Forward-only attribution: only sessions Scarf starts with a project context get mapped; CLI- started sessions still surface in the global Sessions sidebar unchanged. New pieces: - Core/Models/SessionProjectMap.swift — Codable sidecar shape (mappings dict + updatedAt timestamp). - Core/Services/SessionAttributionService.swift — load / attribute / forget / reverse-lookup, all idempotent, all going through atomic write. - HermesPathSet.sessionProjectMap — canonical path resolution. ## Chat plumbing ChatViewModel.startNewSession and the private startACPSession gain an optional projectPath parameter. When non-nil it overrides the default cwd = context.resolvedUserHome() and, on successful session creation, SessionAttributionService.attribute is called. Default-nil call sites keep v2.2 behavior exactly — terminal-mode chats and the global "New Chat" button are unaffected. ## Coordinator handoff AppCoordinator gains pendingProjectChat: String?. The per-project Sessions tab sets it + switches selectedSection = .chat. ChatView observes it (.task cold-launch + .onChange live), consumes the path by calling startNewSession(projectPath:), and clears the field. Clean separation: the Projects feature never reaches into ChatViewModel directly. ## UI - New DashboardTab.sessions case in ProjectsView. Tab bar now always renders when a dashboard is loaded (was gated on siteWidget before); .site still filters out when there's no webview widget. - ProjectSessionsView — per-project session list with a "New Chat" button. Empty-state hint distinguishes "no attributions yet" from "stale sidecar entries". Reuses HermesDataService.fetchSessions and filters by the attribution map. - ProjectSessionRow — local row view independent of the global sessions sidebar so the two can evolve separately. ## Tests SessionAttributionServiceTests (7 tests): - Missing file → empty map - attribute writes + persists via fresh service instance - attribute is idempotent (same pair twice doesn't bump timestamp) - re-attribute changes mapping (session moves between projects) - reverse lookup returns all + distinguishes by project - forget removes mapping, is idempotent on missing sessions - Corrupted JSON → empty map, no crash 80/80 Swift tests pass (was 73; 7 new). 24/24 Python tests still pass. Both prep + feature commits stand independently; commit 3 depends on commit 1 (folder/archive fields) and commit 2 (sidebar UI) only for the full flow to work end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
585d035fe8 |
feat(projects): folder hierarchy + rename/archive/search in the sidebar
Second of three v2.3 commits. Replaces the flat projects sidebar with a hierarchical view that honors the folder + archived fields introduced in commit 1. ProjectsView's inline 70-line `projectList` becomes a one-call invocation of a new extracted `ProjectsSidebar` view. The parent keeps all sheet state (add / rename / move / uninstall / remove- from-list confirmation); the sidebar routes user intent up via closures. That separation means future sidebar changes (drag- and-drop, tags, color labels from the roadmap) don't need to touch ProjectsView's sheet wiring. ProjectsSidebar.swift renders, top to bottom: - Search field (filters by name / path / folder label, live) - Top-level projects (folder is nil or empty, not archived) - One DisclosureGroup per folder, alphabetically sorted, expanded by default on first render; collapsed state persists per view instance. Newly-created folders auto-expand so moves are visibly reflected. - An "Archived (N)" DisclosureGroup at the bottom, surfaced only when the Show Archived toggle in the bottom bar is on. Archived rows render at 0.7 opacity for a subtle visual cue. Bottom bar gains a Show Archived toggle next to the existing + button, using the archivebox SF Symbol (filled when on). Context menu gets three new entries alongside the existing ones: - Rename… — opens RenameProjectSheet with duplicate-name + empty-name validation. - Move to Folder… — opens MoveToFolderSheet with current folder pre-selected; picker lists Top Level, existing folders, and a "New folder…" option that gates on a text field. - Archive / Unarchive — flips the archived bit via the VM. Both new sheets live as standalone files (RenameProjectSheet, MoveToFolderSheet) for reuse — the wiki doesn't need updating; these are pure UI refinements. Selection binding round-trips through `viewModel.selectedProject` unchanged, so the existing dashboard / Site tab routing is unaffected. Sidebar matches use localizedCaseInsensitiveCompare so folder labels and project names sort the way users expect in non-English locales. 73/73 Swift tests still pass (no new tests in this commit — the VM verbs already exercised in ProjectsViewModelTests; the UI is visual and will be validated by the manual smoke test at the end of the branch). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
f1e8f3070f |
feat(projects): registry schema v2 — folder + archived fields
First of three v2.3 commits. Adds the data model + view-model plumbing for folder grouping and soft-archive; no UI changes yet (sidebar still renders a flat list). ProjectEntry gains two optional fields: - `folder: String?` — opaque single-level label for sidebar grouping; nil means top-level. Custom Codable decodeIfPresent so v2.2 registry files parse cleanly. - `archived: Bool` — soft-delete flag; defaults to false via custom decoder. Archived projects stay on disk and in the registry; the v2.3 sidebar just hides them unless Show Archived is toggled on. Custom encode(to:) omits both fields when they're at their default values. Keeps registry files clean for the common (top-level, unarchived) case and means v2.2 Scarf still loads a v2.3-written registry of projects that never used the new features — forward + backward compat by construction. ProjectsViewModel grows four verbs: - moveProject(_:toFolder:) — update the folder assignment - renameProject(_:to:) — rename with duplicate-name + empty-name rejection; preserves selection across the rename so the user stays on the same project - archiveProject(_:) — sets archived=true, clears selection if the archived project was selected (avoids lingering on a hidden view) - unarchiveProject(_:) — sets archived=false; does NOT re-select (unhiding ≠ focusing) - `folders: [String]` computed property — distinct folder labels, sorted, for the sidebar + move-to-folder sheet Two new test suites: - ProjectRegistryMigrationTests: round-trips v2.2 → v2.3 and back, asserts encoder cleanliness (defaults omitted), identity stability under folder / archive changes. - ProjectsViewModelTests: verbs hit the real ~/.hermes/scarf/projects.json via TestRegistryLock for cross-suite serialization. Covers happy paths, duplicate / empty-name rename rejection, and folder dedup. 73/73 Swift tests pass (was 58; 15 new). No behavior change on v2.2 registry files yet — the sidebar UI lands in commit 2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
f366057cfd |
docs(roadmap): add Projects System Evolution section
Captures the backlog discussed during v2.3 planning so future sessions can pick up items without re-deriving the terrain: - v2.3 (planned, in this branch): folders + rename/archive/search + per-project Sessions tab via a sidecar attribution file. - v2.4+: per-project activity feed, token rollup, cron filter, desktop notifications — all "filter existing data via the sidecar" work, unblocked once v2.3 ships. - v2.5+: platform bets (Hermes upstream sessions.cwd column, per-project memory slice, per-project skills namespace, cross-project meta-dashboards, project backup/restore). - Continuous polish: drag-and-drop, tags, favorites, recents, color labels, starter dashboards, opportunistic backfill. - Known research gaps to chase when relevant. No code change; pure docs. Commits to the feature branch because the v2.3 planning context originated there; lands on main with the merge. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
fd0d923c0b |
chore(assets): switch AppIcon set to macOS-native filenames
Exported from Apple Configurator / Icon Composer with the macOS naming template instead of the iOS one (rose from having the wrong template selected in the asset-set's original export). The actual PNG contents match the sizes the macOS AppIcon expects at every 1x/2x density; Contents.json reorders to reference the new names. No visual change for users — the Finder / Dock / about-box icon render identically because the rendered pixels are unchanged at each size. File replacement is purely naming / organizational. Uploaded as a prep commit on the v2.3-projects feature branch since the icon tweak was sitting in the working tree and shipping it separately from the feature work would require an extra release cycle for no benefit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
3c2d11470f | chore: Bump version to 2.2.1 v2.2.1 | ||
|
Alan Wizemann
|
dcd2f8f04b |
docs: v2.2.1 release notes
Covers the four commits landed since v2.2.0: - New catalog template: awizemann/template-author (scaffolding skill) - Config sheet fix: EnumControl always uses Menu picker, not Segmented (the long-option-label overflow that clipped the form) - Config sheet fix: maxWidth constraint on inner VStacks so descriptions with unbreakable tokens wrap cleanly - SKILL.md authoring guidance: prefer markdown link syntax over raw URLs - Devops: scripts/catalog.sh accepts git worktrees release.sh picks up this file as the GitHub release body. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Alan Wizemann
|
ef3ddcdd7a |
fix(config-sheet): EnumControl always uses Menu picker, never Segmented
The Configuration sheet's clipping bug persisted after the earlier
VStack maxWidth fix (
|
||
|
Alan Wizemann
|
5e207f760d |
docs(skill): warn authors against raw URLs in field descriptions
Pairs with the config-sheet wrap fix in
|
||
|
Alan Wizemann
|
d616935296 |
fix(config-sheet): wrap wide schema descriptions instead of clipping
The Configuration sheet rendered field labels chopped on the left
and description URLs spilling off the right whenever a schema
description contained a raw `https://…` URL. Root cause is layout:
SwiftUI's inline-markdown renderer turns the URL into an
unbreakable AttributedString link token, and without an explicit
maxWidth constraint on the sheet's inner VStack, width resolution
went bottom-up — the description's ideal width became the URL's
character length, the VStack matched it, the ScrollView's content
exceeded the sheet's `.frame(minWidth: 560)` viewport, the window
clipped the grown sheet, and the center-aligned result cut off
both sides.
Added `.frame(maxWidth: .infinity, alignment: .leading)` in two
places:
- TemplateConfigSheet's inner VStack inside the ScrollView +
the fieldRow VStack.
- TemplateInstallSheet's main-preview VStack inside its
ScrollView — same pattern, same failure mode for raw URLs in
cron prompts or README blocks (the disclosure-group inner
ScrollViews already had the modifier).
With the constraint, the description's
`.fixedSize(horizontal: false, vertical: true)` wraps at
whitespace boundaries as intended. The URL stays on its own line,
still clickable, still showing the full href. Long paths and
other unbreakable tokens render the same way.
Found while rendering a user-authored schema with two raw URLs
in descriptions. SKILL.md gets a paired update (separate commit)
teaching authors to prefer `[link text](https://…)` markdown
syntax so the visible description stays short even when the href
is long.
58/58 Swift tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Alan Wizemann
|
ea4032766b |
feat(templates): ship awizemann/template-author skill bundle
A new .scarftemplate in the public catalog whose only content is
a Hermes skill that teaches an agent how to scaffold a new
Scarf-compatible project — dashboard, optional configuration
schema, optional cron job, AGENTS.md — from a short conversational
interview. Scaffolded projects are usable locally and cleanly
exportable as .scarftemplate bundles later.
The skill itself (~400 lines of structured markdown at
skills/scarf-template-author/SKILL.md) covers:
- When to invoke vs. when to answer inline
- The on-disk project shape Scarf expects
- A 5-question interview flow
- Full widget catalog (all 7 widget types) with JSON shapes
- Config schema design + hard invariants (no defaults on secrets,
`contents.config` must match field count, etc.)
- Cron-job design including the {{PROJECT_DIR}} gotcha
- Step-by-step file writing (dashboard, manifest, AGENTS.md, README)
- Testing + catalog validation instructions
- Common pitfalls + source-of-truth references
Delivered as a .scarftemplate so the install flow's normal
safeguards apply: preview sheet shows one project + one skill
+ zero cron jobs + no config step, uninstall drops both the
project dir and the namespaced skill folder via the existing
lock-file mechanism.
Scope per user sign-off: blank-slate / fully conversational for
v1. Pre-baked archetypes (`monitor`, `dev-dashboard`, etc.) are
deferred to v1.1 pending real usage data on what shapes users
actually ask for.
New Swift test exercises the bundle through the installer's
plan builder — asserts manifest shape, that the skill lands at
~/.hermes/skills/templates/awizemann-template-author/scarf-template-author/SKILL.md,
and that no-config templates correctly skip the manifest cache.
58/58 Swift tests pass; 24/24 Python tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Claude
|
4132cb03e2 |
rebase: add import ScarfCore to templates feature Mac files
The v2.2.0 templates/config/catalog feature (introduced on main after M0 branched) added 18 Mac-target files that reference types now living in ScarfCore — ServerContext, ProjectEntry, ProjectDashboardService, etc. After rebasing scarf-mobile-development onto main, those files need `import ScarfCore` the same way the M0a/M0c/M0d extractions added it to the ~100 pre-existing Mac files. Unblocks Xcode compile of the scarf (Mac) target on this branch; no behavior change. https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y |
||
|
Claude
|
44d2d6d6c6 |
iOS port M6: YAML parser port, Settings view, Cron editing
Ports the Mac app's YAML parser into ScarfCore, unlocking iOS
Settings. Adds Cron editing (add / delete / toggle / edit). Settings
stays read-only this phase (writes need a round-trip-preserving YAML
writer — out of scope). App Store submission deferred to a later
task per the brief.
## ScarfCore — YAML infrastructure
Packages/ScarfCore/Sources/ScarfCore/Parsing/HermesYAML.swift:
- ParsedYAML struct (values / lists / maps)
- HermesYAML.parseNestedYAML(_:) — indent-based block parser
- HermesYAML.stripYAMLQuotes(_:) — single-layer quote stripping
Lifted verbatim from HermesFileService.parseNestedYAML/stripYAMLQuotes
and hoisted into a standalone namespace. Scope unchanged: the subset
Hermes's config.yaml actually uses (block nesting, scalars, bullet
lists, nested maps). NOT full YAML-spec compliance.
Packages/ScarfCore/Sources/ScarfCore/Parsing/HermesConfig+YAML.swift:
- HermesConfig.init(yaml:) — ports HermesFileService.parseConfig
one-for-one. Every default, every key, every legacy fallback
(platforms.slack.* vs slack.*, command_allowlist vs permanent_
allowlist, etc.) matches the Mac implementation.
- Forgiving: malformed YAML produces partial state + defaults
rather than throwing. Callers surface the raw text so users can
diagnose parse failures on their own.
## ScarfCore — Cron editing (write paths)
Packages/ScarfCore/Sources/ScarfCore/ViewModels/IOSCronViewModel.swift:
- toggleEnabled(id:)
- delete(id:)
- upsert(_:)
All funnel through private saveJobs(_:) which encodes the full
CronJobsFile (.prettyPrinted + .sortedKeys), writes atomically via
transport.writeFile (Data.write-atomic from M5). Creates the cron/
directory on fresh installs.
Models/HermesCronJob.swift — both HermesCronJob and CronJobsFile
gained real public memberwise inits (Swift's synthesis was
suppressed by the hand-written Codable; first draft hacked around
this with JSON round-trips). Also HermesCronJob.withEnabled(_:)
does clean field passthrough instead of encode→mutate→decode.
## ScarfCore — iOS Settings VM
Packages/ScarfCore/Sources/ScarfCore/ViewModels/IOSSettingsViewModel.swift:
- Reads ~/.hermes/config.yaml via ServerContext.readText
- Parses with HermesConfig(yaml:)
- Surfaces both parsed config and rawYAML
- M6 read-only by design — config.yaml needs round-trip-preserving
YAML serialization (comments, key order, whitespace) for safe
edits; option (a) hand-write one, (b) YAML library dep, (c)
delegate to `hermes config set` via ACP. Defer.
## iOS app
Scarf iOS/Settings/SettingsView.swift:
- Read-only browser grouped into 10 sections matching the Mac
app's tabs. DisclosureGroup at the bottom reveals raw YAML
source for diagnostics.
Scarf iOS/Cron/CronListView.swift rewritten:
- Toggle-enabled circle (tap to flip, saves atomically)
- Swipe-to-delete
- "+" toolbar for new job → editor sheet
- Row-tap opens editor with existing fields populated
New CronEditorView form:
- Name, Prompt, Enabled toggle
- Schedule: kind picker (cron/interval/once), display, expression
(for cron), run_at (for once)
- Optional model + comma-separated skills + delivery route
- Preserves runtime fields (nextRunAt, lastRunAt,
deliveryFailures, etc.) when editing existing jobs — no reset
Dashboard's Surfaces section gains a 5th row: Settings.
## Test-suite reorganization (real bug caught)
swift-testing's `.serialized` trait serializes WITHIN one @Suite, not
across suites. Shipping M6 revealed a 3-way race on
`ServerContext.sshTransportFactory`:
- M5's `.serialized` suite sets factory, runs, restores.
- M6's `.serialized` suite did the same in parallel — clobbered.
- M0b's non-serialized `serverContextMakeTransportDispatches`
asserted the DEFAULT factory (nil) returned SSHTransport —
saw whichever factory was temporarily installed.
Fix: one serialization domain for everything that touches the
factory. Move cron-editing + settings-load M6 tests into M5's
serialized suite. M0b's factory-dependent assertion (SSHTransport
fallback) also moves to the M5 serialized suite with an explicit
`factory = nil` reset for race-freedom. Pure YAML/config/memberwise
tests stay in the new plain (non-serialized) M6ConfigCronTests
suite — they never touch globals.
## Test results: 108 → 134 passing on Linux
19 new in M6ConfigCronTests:
- YAML parser: scalars, bullets, nested maps, comments, quotes,
inline {} / []
- HermesConfig.init(yaml:): empty → defaults, model + agent,
display, security + blocklist domains, slack legacy fallback,
auxiliary (3 populated + 2 defaulted), permanent_allowlist vs
command_allowlist, quoted strings
- Memberwise inits for HermesCronJob, withEnabled(_:),
CronJobsFile, CronSchedule
7 new in M5FeatureVMTests (.serialized):
- defaultFactoryProducesSSHTransportForRemoteContext (moved +
hardened with explicit factory reset)
- cronUpsertCreatesFileFromScratch, cronToggleEnabledPersists,
cronDeleteRemovesJob, cronUpsertReplacesMatchingId,
cronPreservesRuntimeFieldsAcrossReloads
- settingsLoadsFromConfigYAML, settingsSurfacesMissingFile
## Manual validation needed on Mac
1. Xcode compile clean.
2. Settings: confirm every section populates from your real
~/.hermes/config.yaml. Tap "View source" disclosure, verify raw
text matches the remote file.
3. Cron: toggle-enabled survives refresh + relaunch. Swipe-delete
works. "+" creates jobs; round-trip name/prompt/schedule/skills.
Edit preserves runtime state.
4. Skills: unchanged from M5 (still browse-only, deferred).
Updated scarf/docs/IOS_PORT_PLAN.md with M6's shipped state, the
YAML-parser scope ceiling, the Settings-edit deferral rationale, and
the cross-suite serialization rule for future test authors.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
6b731ddfb8 |
iOS port M5: Chat polish + Memory + Cron + Skills features
Fleshes out the iOS app from "Chat + placeholder Dashboard" into a
real on-the-go Hermes companion: Chat now renders tool calls + tool
results + permission sheets + markdown + chain-of-thought, and the
Dashboard gains three new feature surfaces.
## Chat polish
scarf/Scarf iOS/Chat/ChatView.swift — several new small SwiftUI
view types:
- ToolCallCard: expandable card for each HermesToolCall on an
assistant message. Tool-kind icon in the header (from
HermesToolCall.toolKind.icon), arguments summary collapsed,
full JSON on tap.
- ToolResultRow: compact "Tool output" disclosure for messages
with role == "tool", shown indented beneath the preceding
assistant bubble.
- PermissionSheet: SwiftUI .sheet(item:) presentation of
RichChatViewModel.pendingPermission. Tapping an option
dispatches ChatController.respondToPermission → ACPClient.
- ReasoningDisclosure: DisclosureGroup for HermesMessage.reasoning,
collapsed by default so chatty thinkers don't dominate scroll.
MessageBubble now renders assistant content through
AttributedString(markdown: options: .inlineOnlyPreservingWhitespace).
User messages stay plain Text (no reason to parse what the user
just typed). Unknown markdown falls through as literal text — worst
case, no formatting.
ChatController gains respondToPermission(requestId:optionId:) that
forwards to ACPClient and clears vm.pendingPermission on the
MainActor.
## New feature surfaces
### Memory (read + edit)
ScarfCore/ViewModels/IOSMemoryViewModel.swift:
- Kind enum (.memory / .user) → maps to paths.memoryMD / .userMD
- text (mutable) + originalText (pristine) + hasUnsavedChanges
- load() / save() / revert()
- async file I/O via ServerContext.readText / writeText — run on
a detached task so the MainActor doesn't hang on remote SFTP
scarf/Scarf iOS/Memory/:
- MemoryListView: two-row NavigationLink (MEMORY.md, USER.md)
- MemoryEditorView: TextEditor bound to vm.text, toolbar Save +
Revert, "Saved" bottom toast on success.
### Cron (read-only)
ScarfCore/ViewModels/IOSCronViewModel.swift:
- Loads ~/.hermes/cron/jobs.json via transport.readFile + decodes
into CronJobsFile (Codable, shipped in M0a)
- Missing file = empty list (no error — common on fresh installs)
- Sort: enabled-first, then nextRunAt ascending, disabled last
- Surfaces decode errors via lastError
scarf/Scarf iOS/Cron/CronListView.swift:
- Row: state-icon + name + schedule.display + next-run-at.
- Detail: prompt, schedule, state, delivery route (via
job.deliveryDisplay), skills, model.
Editing is deferred — needs atomic jobs.json rewrites. Shipped the
read path so users can at least audit their cron config on the go.
### Skills (read-only)
ScarfCore/ViewModels/IOSSkillsViewModel.swift:
- Scans ~/.hermes/skills/<category>/<name>/ via transport.listDirectory
+ transport.stat for directory-ness
- Filters dotfiles. Skips empty categories. Swallows per-category
listing errors (permissions etc.) rather than failing the whole
load.
- requiredConfig stays empty — YAML frontmatter parsing deferred
(would need a parser in ScarfCore; see M5 plan note).
scarf/Scarf iOS/Skills/SkillsListView.swift:
- Grouped by category, tap → SkillDetailView (path + file list).
## Supporting tweaks
- RichChatViewModel.PendingPermission: fields + public init promoted
from `let`/internal to `public let` / `public init(...)` so
PermissionSheet can read title/kind/options and tests can construct
one directly.
- LocalTransport.writeFile refactored to use Data.write(options: .atomic)
instead of FileManager.replaceItemAt. replaceItemAt is Apple-only;
Linux swift-corelibs doesn't fully implement it, which was breaking
the M5 save-path tests on Linux CI. Data.write(atomic) is cross-
platform and has identical semantics (temp-file + rename). Also
auto-creates the parent directory if missing, folding in the one
bit of the old logic that wasn't atomicity-related.
- DashboardView: single Chat Section → "Surfaces" Section with four
NavigationLinks (Chat / Memory / Cron / Skills).
## Tests (ScarfCoreTests/M5FeatureVMTests, 10 new)
.serialized suite — tests install a `withLocalTransportFactory`
helper that swaps ServerContext.sshTransportFactory to produce a
LocalTransport against real tmp files (so .ssh contexts in the
test resolve to local FS paths). Restored in defer. Serialized
because the factory is a static.
- memoryLoadsEmptyWhenFileMissing
- memoryRoundTripsFileContent — seed file → load → edit → save
→ reload via fresh VM → confirm persistence
- memoryRevertRestoresOriginal
- memoryKindPathRouting — pin .memory → memoryMD etc.
- cronEmptyWhenJobsFileMissing — missing file is not an error
- cronLoadsAndSortsJobs — 3-job fixture, verify sort:
enabled-before-disabled and
nextRunAt-ascending within
- cronSurfacesDecodeErrors — garbage jobs.json
- skillsEmptyWhenDirMissing
- skillsScansCategoryAndSkillStructure — 2 categories, dotfile
filter check
- skillsSkipsEmptyCategories
- pendingPermissionMemberwise — SQLite3-gated (RichChatViewModel
is gated)
**108 / 108 passing on Linux** (98 → 108).
## Manual validation needed on Mac
1. Xcode compile clean against M5 source additions.
2. Chat: trigger a tool call + a permission request. Verify cards
render, options dispatch, markdown looks right.
3. Memory: edit MEMORY.md on phone → save → confirm via `cat` on
the remote.
4. Cron: existing jobs show sorted + detail view useful.
5. Skills: browse matches `ls ~/.hermes/skills/<cat>/<name>/`.
Updated scarf/docs/IOS_PORT_PLAN.md with M5's scope, rationale
for the LocalTransport.writeFile refactor (Linux CI), and the M6
Settings-blocker (needs YAML parser port).
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
bd6e722029 |
iOS port M4: Chat via SSHExecACPChannel (Citadel exec bidirectional)
First real interactive iOS feature. Streams JSON-RPC over a
Citadel 8-bit-safe exec channel to a remote `hermes acp` process.
Reuses ScarfCore's `RichChatViewModel` state machine (from M0d)
+ `ACPClient` (from M1) unchanged — the only new code is the iOS-
specific channel + factory + SwiftUI view.
## SSHExecACPChannel
Packages/ScarfIOS/Sources/ScarfIOS/SSHExecACPChannel.swift
(iOS counterpart to Mac's ProcessACPChannel)
Uses Citadel's `SSHClient.withExec(_:perform:)`:
- RFC 4254 exec channel, no PTY, binary-clean stdin/stdout for
JSON-RPC bytes.
- Bidirectional: `TTYStdinWriter` for our `send(_:)` writes,
`TTYOutput` stream for stdout/stderr.
- withExec's closure-scoped lifecycle handled by running it in
a detached Task. A per-actor pending-waiters queue lets the
first `send(_:)` block until the writer is handed over (one-
time RTT); subsequent sends are instant.
- `close()` cancels the Task, which drops the `withExec`
closure, which triggers Citadel to close the SSH channel.
Clean teardown.
- Line framing via `Data` accumulators for stdout + stderr
separately — Citadel yields bytes in arbitrary chunk sizes,
we only push complete (newline-terminated) lines into the
ACPChannel streams.
## ACPClient+iOS
Packages/ScarfIOS/Sources/ScarfIOS/ACPClient+iOS.swift
(Sibling to Mac's ACPClient+Mac.swift)
Exposes `ACPClient.forIOSApp(context:keyProvider:)`. Opens a
dedicated `SSHClient` per ACP session — NOT reusing the
`CitadelServerTransport` client. Rationale: ACP sessions can
run for minutes/hours of streaming chat, and OpenSSH caps
concurrent channels per connection at ~10. Two separate
connections (transport + ACP) stay well under.
SSH auth: ed25519 via the Keychain-stored bundle, same
`SSHAuthenticationMethod.ed25519(...)` path as
CitadelServerTransport.
## iOS Chat view
scarf/Scarf iOS/Chat/ChatView.swift + embedded ChatController
(@Observable @MainActor). Minimal v1 UX:
- Three-state lifecycle: .connecting / .ready / .failed(reason)
- Auto-scrolling message list
- SwiftUI composer (multi-line TextField + Send button)
- Toolbar "+" for a fresh session (stop → reset → start)
- Message bubble (user: accent; agent: secondary background)
Deferred to M5: tool-call cards, permission request sheets,
markdown rendering, voice.
scarf/Scarf iOS/Dashboard/DashboardView.swift gains a
NavigationLink into Chat.
## Small public-API tweak
`RichChatViewModel.sessionId` promoted from `private(set)` to
`public private(set)` — ChatController reads it to route
`sendPrompt`. Same pattern as earlier M3 public-nits patches.
## Tests: 2 new in M4ACPIOSTests (now 98/98 on Linux)
Deliberately focused — M1's 10-test MockACPChannel suite already
covers the full ACPClient state machine. These two pin the
patterns iOS's new SSHExecACPChannel exercises:
- streamingPromptDeliversChunksAndCompletes: full handshake +
session/new + streamed agent_message_chunk notifications +
session/prompt response. Verifies chunks arrive as
.messageChunk events and prompt resolves with correct usage
tokens.
- permissionRequestYieldsEventAndRespondSends: remote
session/request_permission request → .permissionRequest
event → respondToPermission writes correct JSON back on the
channel with matching id + outcome.
Running `docker run --rm -v $PWD/Packages/ScarfCore:/work
-w /work swift:6.0 swift test` now reports 98 / 98.
## Manual validation needed on Mac
1. Xcode compile of scarf mobile target against the merged
pbxproj (target reconciliation shipped in the previous commit
on this branch).
2. Chat end-to-end against a real Hermes host. From Dashboard,
tap Chat → type "hello" → streaming response. Test "+" for
new session. Verify no leaked SSH connections across
Disconnect + re-onboard.
3. If your Hermes enables tools: verify tool_call_update
notifications come through (won't render with fancy cards
yet — that's M5 polish).
Updated scarf/docs/IOS_PORT_PLAN.md with M4's shipped state, the
"two separate SSH clients" rule, and the M5 polish backlog
(tool cards, permissions, markdown, voice).
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
110611549e |
iOS target reconciliation: integrate Xcode-created scarf mobile target
Three-way reconciliation of:
- my M2/M3 source tree at scarf/scarf-ios/
- Alan's Xcode-created target with folder scarf/Scarf iOS/ and
target name `scarf mobile` (bundle com.scarf-mobile.app)
- the Mac `scarf` target that already had ScarfCore wired in
Alan created the iOS target on the unrelated `template-configuration`
branch (commit
|
||
|
Claude
|
92ac102f46 |
M3 follow-up: SETUP.md rewritten for single-project approach
Q: Should I just create an iOS target in the current scarf project?
Would that be easier?
A: Yes — single scarf.xcodeproj with two targets (scarf + scarf-ios)
is objectively easier than a separate scarf-ios.xcodeproj.
The original conservative recommendation (separate xcodeproj) was
rooted in my not wanting to hand-edit pbxproj. But you're the one
clicking through Xcode's UI to create the target, not me — Xcode
handles multi-target multi-platform projects natively, with zero
risk to the existing Mac target.
Rewrote SETUP.md to describe the single-project flow:
- `File → New → Target` inside the existing project (not a new
project file).
- Both targets share the same SPM package references — ScarfCore
is already there for Mac, you just add it + ScarfIOS to the
scarf-ios target via General → Frameworks.
- One Xcode window, one scheme switcher, unified signing/team
settings.
Also threaded in M3-specific smoke-test steps (connect to a real
host → see Dashboard load via Citadel SFTP snapshot) and added a
post-M3 troubleshooting entry for the `Cannot find 'Process' in
scope` error — it should never appear now that makeProcess is
`#if !os(iOS)`-guarded, but if it does it's a leaked Mac-only file
in the scarf-ios target membership.
Milestone status table in SETUP.md updated to reflect M3 shipped.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
e85a7b170c |
iOS port M3: CitadelServerTransport + fix critical iOS compile blocker
Three things this phase ships:
## 1. Critical iOS-compile fix (latent from M0b)
`ServerTransport.makeProcess(...) -> Process` was iOS-unavailable at
compile time but my Linux CI didn't catch it (swift-corelibs-foundation
has Process; Apple iOS does not). Without this fix, the first ⌘B on
the iOS target would fail with "Cannot find 'Process' in scope".
Wrapped `makeProcess` with `#if !os(iOS)` on:
- the ServerTransport protocol requirement
- LocalTransport's impl
- SSHTransport's impl
Every current caller of makeProcess is already Mac-target-only
(ACPClient+Mac.swift, OAuthFlowController.swift) so no code changes
needed outside ScarfCore.
## 2. New platform-neutral streamLines(_:args:)
`AsyncThrowingStream<String, Error>` on the protocol, one stdout
line per element, newline-framed. Stream finishes on EOF + throws
`TransportError.commandFailed` on non-zero exit.
Impls:
- LocalTransport: Task.detached → Process + Pipe → line-framing
loop → exit check. iOS returns an empty stream (iOS doesn't run
LocalTransport at runtime).
- SSHTransport: same pattern, wrapped in `ssh -T host -- sh -c`.
iOS gets the empty-stream stub.
- CitadelServerTransport: empty stream for M3; M4 wires it to
Citadel's raw exec channel for iOS log tailing + chat.
HermesLogService refactored to use transport.streamLines() for the
remote tail path. The old `remoteTailProcess: Process?` +
`fileHandle: FileHandle?` state collapses into a single
`remoteTailTask: Task<Void, Never>?`. Parsed-line ring buffer is
drained synchronously by readNewLines() — semantically identical
on Mac, and newly works on iOS (when Citadel wires streamLines
in M4+).
## 3. CitadelServerTransport (the meat of M3)
Full `ServerTransport` conformance in ScarfIOS:
- File I/O: SFTP via SSHClient.openSFTP()
- runProcess: SSHClient.executeCommand(_:) with 2>&1 folding
- snapshotSQLite: remote `sqlite3 .backup` then SFTP-download
to <Caches>/scarf/snapshots/<id>/state.db
- fileExists/stat: SFTPClient.getAttributes
- listDirectory: SFTPClient.listDirectory with . / .. stripped
- createDirectory: mkdir -p semantics (walks each component,
ignores existing-dir errors)
- removeFile: SFTPClient.remove, idempotent on missing
- watchPaths: 3s polling on stat mtime (same shape as Mac
SSHTransport's remote-watch fallback)
- streamLines: empty stream for M3 (see above)
Maintains a single long-lived SSH + SFTP connection per transport
instance via a nested ConnectionHolder actor. Lazy-init on first
use, reconnect on failure. Blocks the caller thread via
DispatchSemaphore to bridge Citadel's async API to
ServerTransport's sync protocol — same pattern the Mac SSHTransport
uses.
## ScarfCore transport-factory injection
New `ServerContext.sshTransportFactory: SSHTransportFactory?`
static. When non-nil, `makeTransport()` routes `.ssh` contexts
through it instead of constructing SSHTransport directly.
scarfApp.init() on iOS wires this:
ServerContext.sshTransportFactory = { id, cfg, name in
CitadelServerTransport(
contextID: id, config: cfg, displayName: name,
keyProvider: { try await KeychainSSHKeyStore().load() ?? ... }
)
}
Mac leaves it nil; default SSHTransport path unchanged.
## iOS Dashboard — real data
New IOSDashboardViewModel in ScarfIOS. Unlike Mac's DashboardViewModel
(uses HermesFileService, still Mac-only), this reads session stats +
recent sessions only — enough for a real iOS Dashboard, none of the
config.yaml / gateway-state / pgrep checks the Mac dashboard shows.
DashboardView on iOS now renders actual data: session count, message
count, tool calls, token totals (input/output/reasoning with K/M
formatting), and the last 5 sessions with their source icons +
relative start times. Pull-to-refresh triggers vm.refresh(). Error
banner with Retry on snapshot/open failures.
## Public API nits (uncovered by the Dashboard work)
HermesDataService.SessionStats member fields + .empty static were
internal-by-default (nested in a public type, sed missed them).
Promoted to public. `lastOpenError` promoted to public private(set).
## Tests — 8 new in M3TransportTests, @Suite(.serialized)
- LocalTransport.streamLines yields one line per newline, drops
partial trailing content, surfaces non-zero exit as
TransportError.commandFailed.
- ServerContext.sshTransportFactory override applies for .ssh,
ignored for .local, nil-falls-back-to-SSHTransport.
- HermesLogService remote-tail pumps scripted streamLines output
through to readNewLines() ring buffer.
- HermesLogService.readLastLines uses runProcess one-shot, as
documented.
Real bug caught in dev: first pass of this test suite had two tests
setting ServerContext.sshTransportFactory + defer-restoring. Swift-
Testing runs in parallel by default — the two tests raced, producing
"entries[2].message is 'z' not 'boom'". Fixed with
@Suite(.serialized) + a note in the suite header explaining why.
Running `docker run --rm -v $PWD/scarf/Packages/ScarfCore:/work -w /work
swift:6.0 swift test` now reports 96 / 96 passing (88 pre-M3 + 8 new).
## Manual validation needed on Mac
1. iOS build with the new protocol guards. ⌘B on iOS simulator —
should compile cleanly. If `Cannot find 'Process' in scope`
still appears anywhere, grep for any unguarded `Process\(\)`.
2. Dashboard end-to-end against a real Hermes host: iPhone
simulator, public key in remote authorized_keys, onboarding →
Dashboard → should see session stats fetched via Citadel SFTP +
exec. Pull-to-refresh should re-snapshot.
3. SQLite snapshot file appears under `<Caches>/scarf/snapshots/
<id>/state.db` and HermesDataService opens it read-only.
Updated scarf/docs/IOS_PORT_PLAN.md with M3's shipped scope, the
streamLines adoption rule, and the "CitadelServerTransport.streamLines
is a stub (M3)" / "M4 wires real streaming" cross-reference.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
3420abae74 |
M2 follow-up: Citadel 0.12.1 (current), pre-built Assets.xcassets
Two follow-ups per review:
## Citadel: current stable
Citadel is at 0.12.1, not 0.9.x as I'd been writing against. Bumped
the pin from `from: "0.7.0"` to `.upToNextMinor(from: "0.12.0")`
— tight because Citadel's pre-1.0 authentication-method variants
have shifted between minor releases (0.7 → 0.9 → 0.12), so
explicit bump-and-review is safer than letting the version float.
Downloaded Citadel 0.12.1's source and verified every API call in
CitadelSSHService against it:
- SSHAuthenticationMethod.ed25519(username:, privateKey:) ✓
- SSHClientSettings(host:, authenticationMethod:, hostKeyValidator:) ✓
- SSHHostKeyValidator.acceptAnything() ✓
- SSHClient.connect(to: settings) ✓
- client.executeCommand(_:) -> ByteBuffer ✓
- client.close() async throws ✓
Dropped the "FIXME — may need adjustment" disclaimer in the file
header; replaced with a "verified against 0.12.1" note that says
re-verify if the pin bumps to 0.13+. Same change in SETUP.md
troubleshooting.
## Assets.xcassets (app icon + accent color)
scarf/scarf-ios/Assets.xcassets/ now exists with:
- AppIcon.appiconset/
AppIcon-1024.png (1024×1024, copied from the Mac app's
icon set — same art)
Contents.json (idiom: universal, platform: ios,
size: 1024x1024 — iOS 14+ renders all
smaller sizes from this automatically)
- AccentColor.colorset/
Contents.json (Scarf teal: sRGB 0.227/0.525/0.722
light, 0.400/0.690/0.902 dark)
- Contents.json (root, empty — just version metadata)
SETUP.md updated:
- Instructs Alan to delete Xcode's scaffolded Assets.xcassets AND
import ours, not the other way around.
- Notes the accent color values so a different palette choice is
a one-file edit.
- Removes the obsolete "drop your icon asset" step.
No functional code changes; tests still 88/88 on Linux.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
ba368d2f6d |
iOS port M2: iOS app skeleton — onboarding, Citadel wrapper, Keychain, Dashboard
First iOS phase. Delivers all the code needed to build + TestFlight a
functional v1 iOS app (onboarding with SSH-key generate / import +
real Citadel-backed connection test; persistent Keychain key +
UserDefaults server config; placeholder Dashboard) — but NOT the
scarf-ios.xcodeproj. Creating that from scratch by hand is too risky
without an iOS SDK to build against, so Alan creates it in Xcode's UI
following scarf/scarf-ios/SETUP.md (~5 minutes, one-time).
## ScarfCore additions (all Linux-testable)
Packages/ScarfCore/Sources/ScarfCore/Security/:
- SSHKey.swift — SSHKeyBundle + SSHKeyStore protocol
+ InMemorySSHKeyStore test actor
- IOSServerConfig.swift — IOSServerConfig + store protocol + mock;
toServerContext(id:) bridges to the
existing ServerContext so all ScarfCore
services work against an iOS config
- OnboardingState.swift — OnboardingStep enum + pure validators
(host, port, PEM shape, public-key parse)
- SSHConnectionTester.swift — protocol + error enum + mock
- OnboardingViewModel.swift — @Observable @MainActor state machine,
fully dependency-injected (key store /
config store / tester / generator closure)
## New Packages/ScarfIOS local SPM package
Depends on ScarfCore + Citadel (from: "0.7.0").
- KeychainSSHKeyStore.swift — real iOS Keychain storage
(kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, no iCloud
sync). Gated on canImport(Security) for Linux skip.
- UserDefaultsIOSServerConfigStore.swift — JSON-encoded single-key
persistence of IOSServerConfig.
- Ed25519KeyGenerator.swift — CryptoKit-backed Ed25519 minting.
Emits standard OpenSSH public-key lines (authorized_keys-ready).
Stores the private half in a compact SCARF ED25519 PRIVATE KEY
PEM shape that CitadelSSHService decodes back into a
Curve25519.Signing.PrivateKey. Non-interop with OpenSSH's
`BEGIN OPENSSH PRIVATE KEY` envelope — export flow for sharing
keys is deferred to a later phase.
- CitadelSSHService.swift — SSHConnectionTester conformance +
key-generation wrapper. Runs `echo scarf-ok` over a one-shot
Citadel exec for the onboarding connection test. One FIXME on
buildClientSettings because Citadel 0.7→0.9 shifted the
`.ed25519(...)` authentication-method variant name; every other
line is Citadel-version-independent. Gated on
canImport(Citadel) && canImport(CryptoKit).
## scarf/scarf-ios/ app source tree
- App/ScarfIOSApp.swift — @main, RootModel routes to
onboarding or dashboard based on
stored state.
- Onboarding/OnboardingRootView.swift — 8 sub-views, one per
OnboardingStep. Validated
server-details form, key-source
picker, generate / show-public
/ import / test / retry /
connected.
- Dashboard/DashboardView.swift — M2 placeholder: connected host
details + Disconnect button.
M3 replaces with real data.
## scarf/scarf-ios/SETUP.md
Step-by-step Xcode project creation:
- iOS 18 / iPhone-only / team 3Q6X2L86C4 / Bundle ID
com.scarf.scarf-ios / Swift 5 language mode.
- Wire Packages/ScarfCore + Packages/ScarfIOS (Citadel resolves
transitively).
- Replace Xcode's default scaffolded files with this source tree.
- Smoke-test procedure (simulator → physical iPhone).
- TestFlight upload steps.
- Troubleshooting for the known Citadel-variant-name drift.
## Test coverage (Linux, `swift test`)
M2OnboardingTests, 26 new tests (ScarfCore):
- SSHKeyBundle memberwise + display fingerprint
- InMemorySSHKeyStore + InMemoryIOSServerConfigStore round-trips
- IOSServerConfig.toServerContext bridging (with + without
remoteHome override)
- All OnboardingLogic validators (empty / whitespace / port range /
legacy-RSA rejection / public-key line parser)
- MockSSHConnectionTester scripting (success + failure)
- 10 OnboardingViewModel end-to-end paths: happy-path
save-and-test, invalid-host blocks advance, connection-failure
routes to .testFailed (and crucially does NOT save config),
retry-after-failure-works, import-happy, import-rejects-bad-PEM,
reset clears all state
ScarfIOSSmokeTests, 3 tests (Apple-only, won't run on Linux):
- Ed25519KeyGenerator bundle shape + base64 wire format
- OpenSSH public-key line byte-length pinned at 51 bytes
- Corrupted PEM rejection on round-trip decode
Running
docker run --rm -v $PWD/scarf/Packages/ScarfCore:/work -w /work swift:6.0 swift test
reports **88 / 88 passing** (62 pre-M2 + 26 new).
## Real bug caught in development
First pass of OnboardingViewModel had `confirmPublicKeyAdded()` set
`isWorking=true`, then call `runConnectionTest()` which bailed on
`!isWorking` — meaning the connection probe never ran and the config
was never saved. Caught by the end-to-end test. Fixed by extracting
the shared probe body into `performConnectionTest()` and letting
both entry points own their own `isWorking` transition.
## Manual validation still needed on Mac
1. Xcode project creation per SETUP.md — confirm the resulting
project builds cleanly.
2. Citadel 0.9.x authentication-method variant — verify the one
FIXME line in buildClientSettings.
3. End-to-end onboarding: simulator against `localhost:22` (or a
test host), then TestFlight → physical iPhone → real SSH host
with the shown public key in authorized_keys.
Updated scarf/docs/IOS_PORT_PLAN.md with M2's shipped scope, the
scope decision about NOT generating the xcodeproj, and the list of
rules M3+ can rely on (Citadel transport dispatch, ChannelFactory
hook, single-server invariant).
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
bdf31d6781 |
iOS port M1: decouple ACPClient from Process via ACPChannel protocol
Introduces the key architectural abstraction that lets iOS share the
ACP state machine with Mac in M4+. ACPClient no longer touches
`Process`, `Pipe`, file descriptors, or SSH sessions directly — it
reads / writes line-oriented JSON-RPC through an `ACPChannel`.
New in ScarfCore/ACP/:
- ACPChannel.swift (protocol + ACPChannelError enum)
- ProcessACPChannel.swift (Mac + Linux; `#if !os(iOS)` guard —
iOS can't spawn subprocesses). Wraps the Process + Pipe +
raw POSIX write(2) code that used to live inline inside
ACPClient: SIGPIPE-ignore, partial-write loops, EPIPE →
`.writeEndClosed`, graceful SIGINT + 2s SIGKILL watchdog.
Uses `canImport(Darwin)` / `canImport(Glibc)` for the
platform-specific `write(2)` binding.
- ACPClient.swift (moved from scarf/Core/Services and refactored).
Process/Pipe/stdinFd/Darwin.write state replaced with a single
`channel: any ACPChannel` reference. Construction takes a
`ChannelFactory = @Sendable (ServerContext) async throws -> any ACPChannel`
closure — Mac wires ProcessACPChannel, iOS will wire a Citadel
SSHExecACPChannel in M4.
Mac-side glue (stays in main target):
- scarf/Core/Services/ACPClient+Mac.swift (new) carries the
`ACPClient.forMacApp(context:)` factory. Internally spawns
`hermes acp` locally or `ssh -T host -- hermes acp` remotely
via SSHTransport.makeProcess, passing the enriched shell env
(local: full PATH + credentials; remote: just SSH_AUTH_SOCK
+ SSH_AGENT_PID) with TERM stripped. Behaviour identical to
pre-M1.
- ChatViewModel updated at 3 sites from `ACPClient(context:)`
to `ACPClient.forMacApp(context:)`.
Public API change callers need to know about:
- `ACPClient.respondToPermission(requestId:optionId:)` is now
`async`. ChatViewModel already `await`ed it, so that upgrade
is a no-op; no other callers.
Also deleted scarf/Core/Services/ACPClient.swift (605 lines;
replaced by ScarfCore version).
Test coverage (M1ACPTests, 10 tests):
Using a MockACPChannel actor to script JSON-RPC deterministically,
not a real subprocess:
- ACPChannel protocol (mock send/receive, write-after-close,
error descriptions).
- ACPClient initial state.
- start() sends initialize and flips isConnected on reply.
- RPC error reply surfaces as ACPClientError.rpcError.
- Mid-flight channel close → pending request resolves with
.processTerminated, isConnected flips false.
- session/update notification routes into the `events` stream
as .messageChunk.
- Stderr lines feed the recentStderr ring buffer.
- ACPErrorHint.classify across credential / missing-binary /
rate-limit / unknown cases.
`swift test` on Linux now reports 62 / 62 passing.
Updated scarf/docs/IOS_PORT_PLAN.md with M1's shipped state, the
behavior-preservation rationale for the Mac factory, and the
iOS hook point M2–M4 will plug into.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
920c86b4f8 |
M0 verification: fix two real regressions before starting M1
Two bugs caught by a post-M0d audit, both of which would have bitten
users before any test exercised them on Mac:
1. GatewayViewModel.swift lost its `import ScarfCore` during the
M0d revert (when I moved it back to the Mac target after finding it
wasn't portable). The file references ServerContext everywhere and
wouldn't compile in Xcode without the import. Added back.
2. SSHTransport.sshSubprocessEnvironment() regressed in M0b.
The original Mac code ran HermesFileService.enrichedEnvironment(),
which tries `zsh -l -i` (login + interactive, with prompt-framework
defangs) FIRST, then falls back to `zsh -l`. Most users with
1Password / Secretive / manual ssh-add export SSH_AUTH_SOCK from
their `.zshrc` (interactive shell init), NOT `.zprofile`. My M0b
replacement used `zsh -l` only — so it would have silently failed
to find their ssh-agent socket, and SSH auth would break with
"Permission denied" (exit 255) for everyone who set up their
agent the normal way.
Fix is a dependency-inversion injection point instead of a local
shell probe: SSHTransport.environmentEnricher is a `(@Sendable () ->
[String: String])?` static that the Mac target wires at launch to
HermesFileService.enrichedEnvironment(). Same exact code path
executed as before M0b; no duplication; iOS leaves it `nil` and
falls back to ProcessInfo.processInfo.environment (Citadel will
own the SSH agent on iOS in M4+, not the login shell). Tests can
set a stub closure.
scarfApp.init() now sets `SSHTransport.environmentEnricher = {
HermesFileService.enrichedEnvironment() }` right before the
existing warm-up Task.
Test coverage: M0b suite gains `sshTransportEnvironmentEnricherInjection`,
which pins the injection-point shape so a future refactor can't
silently drop it.
Audit results (for confidence before M1):
- Exhaustive grep of every moved type across main target → 0 files
reference ScarfCore types without `import ScarfCore` (after the
GatewayVM fix).
- `scarf.xcodeproj/project.pbxproj` has no stale path references
(PBXFileSystemSynchronizedRootGroup auto-discovers).
- `xcshareddata/xcschemes/*.xcscheme` has no stale path references.
- `.build/` correctly gitignored.
- Zero leftover temp scripts / `.orig` / `.bak` files.
`swift test`: 52 / 52 passing on Linux.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
8bd4b9282a |
iOS port M0d: extract 6 portable ViewModels to ScarfCore
Fourth and final M0 sub-PR. Wraps up the ScarfCore extraction with the
ViewModels that have no dependency on Mac-target services or AppKit.
Views deliberately stay in the Mac target — see plan for rationale.
Moved (6 VMs):
ActivityViewModel.swift — HermesDataService consumer, SQLite3-gated
ConnectionStatusViewModel.swift — @MainActor heartbeat for remote SSH
InsightsViewModel.swift — HermesDataService aggregator, SQLite3-gated
(+ InsightsPeriod, ModelUsage, PlatformUsage,
ToolUsage, NotableSession types; exports
free functions formatDuration/formatTokens)
LogsViewModel.swift — HermesLogService consumer, fully portable
(+ nested LogFile / LogComponent enums)
ProjectsViewModel.swift — ProjectDashboardService wrapper, portable
RichChatViewModel.swift — ~700 lines of ACP-event + message-group
handling, SQLite3-gated
(+ ChatDisplayMode, MessageGroup types)
Reverted in-flight:
GatewayViewModel.swift — my audit missed that it calls
`context.runHermes(...)`, a Mac-target-only extension. Not portable
without moving HermesFileService too. Left in the Mac target.
Platform guards applied:
- `#if canImport(SQLite3)` wraps entire files for ActivityVM, InsightsVM,
and RichChatVM (they transitively depend on HermesDataService).
- `#if canImport(Darwin)` around LocalizedStringResource displayName
in LogsViewModel's nested LogFile and LogComponent enums.
- `#if canImport(os)` around the unused Logger in
ConnectionStatusViewModel (kept the field for future use).
Swift 6 / Observation notes:
- `import Observation` explicitly added to each @Observable file.
Mac target gets Observation via SwiftUI; ScarfCore doesn't import
SwiftUI, so it needs the explicit module import. Observation ships
in the Swift 5.9+ standard library on every platform.
- Nested enums' `var id: String { rawValue }` had to be manually
promoted to `public var id` since my sed only touches 4-space-indent
declarations and the nested enum's members are at 8-space indent.
- Two accidentally-publicized function-local `let` variables in
InsightsViewModel reverted back to internal.
- Sed adjustment: an earlier pattern was producing `@Observable public`
which is a Swift syntax error. Fixed post-hoc by stripping the
stray trailing `public` after the attribute; noted in the plan file
as a checklist item for M1+ sed work.
Consumer import sweeps:
4 Mac-target files gained `import ScarfCore` for the moved VM types:
ContentView.swift, ChatView.swift, RichChatView.swift, and
ConnectionStatusPill.swift.
Test coverage (M0dViewModelsTests): 14 new tests.
- ConnectionStatusViewModel: local-always-connected, remote idle-start,
Status Equatable pinning.
- LogsViewModel: init defaults, filteredEntries across level / search /
component filters, nested enum Identifiable ids and loggerPrefix.
- ProjectsViewModel: .local context binding.
- (SQLite3-gated, Apple-only):
ActivityVM construction, InsightsVM period defaults and sinceDate
ordering, ChatDisplayMode case coverage, RichChatVM empty-state
invariants, MessageGroup derived properties.
Running `docker run --rm -v $PWD/scarf/Packages/ScarfCore:/work -w /work
swift:6.0 swift test` now reports 51 / 51 passing on Linux
(M0a 16 + M0b 18 + M0c 8 + M0d 9 + smoke 1 − 5 SQLite3-gated).
Apple-target CI should see 56 / 56 with the 5 gated tests added in.
Updated scarf/docs/IOS_PORT_PLAN.md with M0d's shipped state, the
Views-stay-Mac-only scope decision, and the sed-gotcha checklist
future phases should watch for.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
27dc694aeb |
iOS port M0c: extract portable Services to ScarfCore
Third of four M0 sub-PRs. Moves the four Services that have no dependency
on Mac-target code or AppKit into ScarfCore, so the Mac + (future) iOS
targets can share them.
Files moved (4):
scarf/Core/Services/HermesDataService.swift (658 lines, SQLite reader + SnapshotCoordinator actor)
scarf/Core/Services/HermesLogService.swift (log tail + parse, LogEntry + LogLevel)
scarf/Core/Services/ModelCatalogService.swift (models.dev JSON reader, HermesModelInfo + HermesProviderInfo)
scarf/Core/Services/ProjectDashboardService.swift (per-project dashboard I/O)
Not moved, with reason:
HermesFileService.swift — carries the big shell-enrichment logic; a
later phase can port once iOS has a clearer env story for ACP spawns.
HermesEnvService.swift — depends on HermesFileService.
HermesFileWatcher.swift — depends on HermesFileService.
ACPClient.swift — M1's job (the ACPChannel refactor).
UpdaterService.swift — wraps Sparkle, stays Mac-only forever.
Platform guards:
HermesDataService.swift is wrapped in `#if canImport(SQLite3) ... #endif`
for the whole file. SQLite3 isn't a system module on Linux
swift-corelibs-foundation. Apple platforms compile unchanged. Linux
builds skip the file entirely; nothing in ScarfCore references
HermesDataService from outside the file, so there's no downstream
fallout.
ModelCatalogService `import os` / Logger definition / call site all
guarded with `#if canImport(os)`. Linux gets silent logging.
HermesLogService + ProjectDashboardService use only Foundation —
no guards needed.
Other fixes:
- Features/Settings/Views/Components/ModelPickerSheet.swift (the one
remaining consumer) gains `import ScarfCore`.
- Self-referential `import ScarfCore` stripped from each moved file.
Test coverage: 8 new tests in ScarfCoreTests/M0cServicesTests.swift:
- HermesLogService.parseLine exercised via readLastLines on a real
tmp file with three formats — v0.9.0+ with session tag, older
without, and garbage fallback. Pins CLAUDE.md's optional-session-tag
invariant.
- LogLevel SwiftUI colour strings pinned.
- HermesModelInfo.contextDisplay across 1M / 200K / 500 / nil cases;
costDisplay with and without costs.
- ModelCatalogService load path end-to-end against a synthetic
models_dev_cache.json lookalike — providers sorted, models
filtered, provider(for:) resolves both full-scan and slash-prefixed
IDs.
- Malformed + missing catalog files return empty, no crash.
- ProjectDashboardService round-trips ProjectRegistry + reads a
synthetic .scarf/dashboard.json.
Running `docker run --rm -v $PWD/scarf/Packages/ScarfCore:/work -w /work
swift:6.0 swift test` now reports 42 / 42 passing (M0a 16 + M0b 18 +
M0c 8).
Updated scarf/docs/IOS_PORT_PLAN.md progress log with the shipped M0c
state and the SQLite3-gating pattern future phases should reuse.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|
||
|
Claude
|
0fd2ceb9fc |
iOS port M0b: extract Transport + ServerContext to ScarfCore
Second of four M0 sub-PRs. Moves the remaining cross-cutting
infrastructure — the ServerTransport protocol and its two implementations
(LocalTransport, SSHTransport), plus ServerContext and its helpers —
into ScarfCore so both Mac and (future) iOS targets share one codebase.
Files moved (5):
- scarf/Core/Transport/ServerTransport.swift (+ FileStat, ProcessResult, WatchEvent)
- scarf/Core/Transport/LocalTransport.swift
- scarf/Core/Transport/SSHTransport.swift
- scarf/Core/Transport/TransportErrors.swift
- scarf/Core/Models/ServerContext.swift (+ SSHConfig, ServerKind, ServerID, UserHomeCache)
Split out of ServerContext.swift into a new Mac-target sibling file
scarf/Core/Models/ServerContext+Mac.swift:
- runHermes(_:timeout:stdin:) — depends on HermesFileService
- openInLocalEditor(_:) — depends on AppKit.NSWorkspace
These methods can't live in ScarfCore itself because ScarfCore must not
depend on main-target services or AppKit. iOS will provide a sibling
ServerContext+iOS.swift in M2+.
Removed: scarf/Core/Models/HermesPaths+Deprecated.swift.
Zero callers in-tree; its only justification was that ServerContext
used to be in the Mac target. With ServerContext in ScarfCore now,
the deprecated forwarders are both unreachable AND dead code.
Breaking the ScarfCore → main-target circular dep in SSHTransport:
The old SSHTransport.sshSubprocessEnvironment() called
HermesFileService.enrichedEnvironment() to harvest SSH_AUTH_SOCK from
the user's login shell. Replaced with a local #if os(macOS) helper
SSHTransport.macLoginShellSSHAgent() that probes /bin/zsh for only
the two SSH agent vars (no PATH/credentials — that's still in
HermesFileService for ACP subprocess use). Behavior-identical on
macOS; no-op on iOS/Linux.
Platform guards added in ScarfCore (runtime targets still macOS/iOS):
- `#if canImport(os)` around os.Logger (definition + every call site,
except the large Darwin-dependent ensureControlDir block).
- `#if canImport(Darwin)` around LocalTransport.watchPaths (FSEvents)
and SSHTransport.ensureControlDir (Darwin.stat/lstat). Linux gets
a no-op empty stream and a best-effort FileManager.createDirectory
fallback — neither is exercised at runtime on Linux, only compiled.
- `#if canImport(SwiftUI)` around ServerContext's EnvironmentKey.
- `#if canImport(AppKit)` inside the new ServerContext+Mac.swift
extension.
Bug fixed: M0a's sed transform accidentally added `public` to protocol
requirements in ServerTransport.swift, e.g. `public nonisolated var
contextID: ServerID { get }`. Swift forbids access modifiers on
protocol requirements — stripped.
54 additional consumer files in the Mac target gained `import ScarfCore`.
Test coverage: 18 new tests in ScarfCoreTests/M0bTransportTests.swift.
Runs on Linux via
docker run --rm -v $PWD/scarf/Packages/ScarfCore:/work -w /work swift:6.0 swift test
Total suite: 34 / 34 passing (M0a's 16 + M0b's 18).
Updated scarf/docs/IOS_PORT_PLAN.md progress log with the shipped M0b
state and the Platform-guard patterns future phases should reuse.
https://claude.ai/code/session_019yMRP6mwZWfzVrPTqevx2y
|