@aitne-sh/aitne 0.1.8 → 0.1.10

package/agent-assets/skills/browser-history-respond/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: browser-history-respond
+description: |
+  Translate the owner's natural-language reply to a research-engagement
+  offer DM into a /api/browser-history/offers/<slug>/{accept|decline}
+  call. Use ONLY when GET /offers/pending returns an open offer AND
+  conversation_history shows a recent offer DM in this channel.
+allowed-tools:
+  - Bash(curl *)
+---
+
+# Browser History — natural-language acceptance bridge
+
+When the owner replies to a research-offer DM ("dig deeper" /
+"summarise"), translate that into the structured dispatch call.
+
+## Hard rule — never cold-call
+
+This skill is a no-op unless BOTH hold:
+
+1. `GET /api/browser-history/offers/pending` returns a non-empty list
+   (call this FIRST). Empty → do nothing; ignore research entirely.
+2. `<recent_dm_conversation>` shows a prior assistant DM that
+   actually offered the two options. No prior offer in the window →
+   the reply is not about research; ignore the pending rows (they
+   resurface in tomorrow's morning digest).
+
+Calling accept/decline when the owner didn't ask is a worse failure
+than missing an ambiguous reply.
+
+## Endpoints
+
+| Method | Path | Purpose |
+|---|---|---|
+| GET | `/api/browser-history/offers/pending` | List open offers (slug, displayName, kind, offeredAt, expiresAt). Call FIRST. |
+| POST | `/api/browser-history/offers/<slug>/accept` | Body `{kind: "research_assist" \| "wiki_summary"}` — dispatch the routine. |
+| POST | `/api/browser-history/offers/<slug>/decline` | Silence both options for this cluster for 14 days. |
+
+No other `/api/browser-history/*` endpoints from this skill — if you
+want to read clusters or shopping, that's a different skill loaded
+for the routine paths, not the DM agent.
+
+## Intent → kind mapping
+
+The owner may reply in any language. Your multilingual understanding
+handles that; the table below gives the *concepts*, not the exact
+phrasing, to anchor the mapping.
+
+| Owner intent | Resolves to |
+|---|---|
+| Accepts the deeper-research offer (variations: "yes", "research", "dig deeper", "research please", "do the research") | `{"kind":"research_assist"}` |
+| Accepts the summarise-the-sites offer (variations: "summarise", "summary", "wiki it", "make a note", "do a wiki") | `{"kind":"wiki_summary"}` |
+| Declines both options (variations: "no thanks", "not now", "skip", "later", "ignore it") | `/decline` |
+| Ambiguous reply ("yeah" / "ok" alone when both options were offered) | **Ask ONE clarifier** — don't guess. |
+
+If the owner names the topic differently from `displayName` (e.g.
+offer about "prompt-injection-defenses", owner says "yes do the CaMeL
+research"), match to the slug — the intent is what matters.
+
+## Slug resolution
+
+If exactly one offer is open: pick it. If two are open (the rate-limit
+gate allows up to 2/day): match `displayName` against what the owner
+referenced, or ask:
+
+> Did you mean **<topic A>** or **<topic B>**?
+
+## Acknowledgement
+
+For accept, only send the success ack if the response has
+`enqueued:true`. If `enqueued:false` the dispatch did not fire (EventBus
+unwired during the boot window) — tell the owner to retry in a moment
+instead of claiming a result is coming.
+
+Send a one-line ack in the owner's `primaryLanguage` (examples English):
+
+- research_assist accepted: "On it — I'll DM the parallel research
+  dive when it lands. Usually 5-10 min."
+- wiki_summary accepted: "Got it — I'll compose the wiki note and DM
+  the destination. A minute or two."
+- decline: "Got it, silenced offers for **<displayName>** for 14 days."
+
+The dispatch routines DM the owner with their result themselves; don't
+pre-summarise.
+
+## Curl shapes
+
+```bash
+curl --silent --fail \
+  http://127.0.0.1:8321/api/browser-history/offers/pending
+
+curl --silent --fail -X POST \
+  -H 'Content-Type: application/json' \
+  -d '{"kind":"research_assist"}' \
+  http://127.0.0.1:8321/api/browser-history/offers/<slug>/accept
+
+curl --silent --fail -X POST \
+  http://127.0.0.1:8321/api/browser-history/offers/<slug>/decline
+```
+
+JSON body in single quotes (project convention) so the daemon hooks
+classify the payload as data, not shell.
+
+## Out of scope here
+
+- Surfacing browser-history data on demand — that's the morning
+  digest's job, not DM time.
+- Composing the offer DM itself — that's `routine.research_offer_dm`.
+- Reading cluster journals / deltas — the dispatch routines do that.
+- Muting / renaming — explicit bang commands (`!research mute
+  <slug>` / `!research rename <slug> <new>`), not natural-language.

package/agent-assets/skills/browser-task/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: browser-task
+description: Hand open-ended browser requests (post a tweet, fill a contact form, check an order status, …) to /api/browser-task. Relay sub-agent clarifications, POST /clarify with the reply, /cancel on stop.
+allowed-tools:
+  - Bash(curl *)
+---
+
+# Browser Task — open-ended browser ops from DM
+
+A scoped sub-agent drives Aitne's managed Chromium turn-by-turn from a
+natural-language description. **It runs as a detached background process
+with its own budget — the daemon DMs the user directly when it finishes,
+needs input, or fails.** You are NOT in that delivery path. Your job is
+the front bookend only: collect intent, POST it, acknowledge in one line,
+and **end your turn**. The Playwright work is invisible to you.
+
+This is NOT the surface for managed-Chromium status, per-site sign-in,
+B-4 purchase tokens, or workflow approvals — those live under
+`/api/browser-history/managed/*`, `/api/browser-automation/sites/*`, and
+`/api/browser-automation/purchase/*`.
+
+## Hard rules
+
+1. **Localhost only.** `http://127.0.0.1:8321/api/browser-task/*`.
+2. **POST, ack, end the turn. NEVER poll for completion.** After a
+   successful POST, reply once ("Started — I'll report back when it's
+   done.") and stop. Do not GET `/:id` in a loop, "wait and check", or
+   re-issue. Ending your turn has zero effect on the detached task — it
+   keeps running and the daemon DMs the user the result (`✅ Browser task
+   — report`) or, on any failure/cancel/timeout, `🟦 Browser task <id>
+   ended: <state>`. The only allowed GET is a single on-demand status read
+   answering an explicit user question (see "On-demand status").
+3. **Never echo the `!~xxxxxxxx` final-confirm token.** The daemon DMs it
+   directly when the sub-agent trips the final-confirm gate. The user
+   types it back themselves; the runner consumes the reply. Do not read,
+   log, paraphrase, or relay the token. If the user asks "what was that
+   code?", point them at the original DM with the screenshot — that DM is
+   the only authoritative source.
+4. **Never invent `clarificationId` / `taskId`.** Both are uuid v4 minted
+   by the daemon; read from GET responses.
+5. **Do not pre-decline based on the URL or site.** Open navigation is
+   the default — the sub-agent decides where to go and the daemon enforces
+   a user-curated hostname denylist plus the payment-path block at
+   navigation time. POST the description as the user asked.
+6. **One task per request.** "Post a tweet AND subscribe …" → two POSTs.
+
+## Endpoints
+
+| Method | Path | Purpose |
+|---|---|---|
+| POST | `/api/browser-task` | Create + dispatch, or schedule for later. |
+| GET | `/api/browser-task?state=...` | List (filter on `state`). |
+| GET | `/api/browser-task/:id` | Detail — state, action log, clarifications. |
+| POST | `/api/browser-task/:id/clarify` | Answer the open clarification. |
+| POST | `/api/browser-task/:id/cancel` | Force-stop a task. |
+
+## POST — composing a request
+
+```bash
+curl --silent --fail -X POST -H 'Content-Type: application/json' \
+  -d '{"description":"Post \"Hello world\" to twitter.com"}' \
+  http://127.0.0.1:8321/api/browser-task
+```
+
+Body:
+
+- `description` (1..4096) — one sentence stating the **end state**, not a
+  step recipe. Name the site in plain language when it matters ("post to
+  X", "check my hitachi.com order status"); the sub-agent decides where to
+  navigate. There is no `siteKey` or `extraAllowedHosts` field — the API
+  dropped both on 2026-05-27 (open navigation). Legacy callers passing
+  them are silently ignored, not rejected.
+- `scheduleAt` (ISO 8601) — defer to later; respects quiet hours.
+  Response is `202` with `{ taskId, status:"scheduled", scheduledFor,
+  scheduleRowId }` (`scheduledFor` is epoch-ms; `taskId` is the same
+  pre-generated id you use for status GETs).
+- `requireFinalConfirm` (default `true`) — keep `true` unless the user
+  explicitly asks to skip the gate for a reversible flow.
+
+Immediate response carries `taskId`, `status`, and `queueState`; then ack
+once and stop (Hard rule 2). If `queueState.waitingForSlot === true`, the
+global cap is full — say so once ("queued behind N task(s); I'll start it
+when a slot opens"). The daemon DMs the user on promote and on finish.
+
+## Relaying a clarification — `awaiting_user`
+
+The daemon DMs the user a question + screenshot via the originating
+channel (you do not author it, and per Hard rule 2 you do not poll for it
+to appear). You act only when the user comes back with an answer:
+
+1. `GET /api/browser-task?state=awaiting_user` — find the parked task.
+   Usually one; if several, match topic or ask which.
+2. `GET /api/browser-task/<taskId>` — read the open `clarifications` row
+   (`resolved:false`) for `clarificationId`.
+3. `POST /api/browser-task/<taskId>/clarify` with `{clarificationId,
+   answer}` (user reply verbatim), then ack briefly and end the turn —
+   the runner resumes on its own.
+
+Status codes — handle each, don't retry blindly:
+
+- `200` — recorded; runner resumes. Brief ack ("Got it, resuming.").
+- `400 validation_error` — `clarificationId` not a uuid or `answer` empty
+  / >8192 chars. Re-read with GET and re-send.
+- `409 not_awaiting_user` — window closed (carries `currentState`). Tell
+  the user the verbatim state; offer re-issue if relevant.
+- `410 expired` — clarification deadline passed; the runner transitions
+  the task to `abandoned` on the next scanner tick. Apologise.
+- `404 not_found` — your state is stale; re-read with GET first.
+
+## On-demand status — only when the user asks
+
+If (and only if) the user explicitly asks how a task is going, do a
+**single** read and summarize — never a loop. `GET
+/api/browser-task?state=running,awaiting_user,pending` (or a `taskId` the
+user names), then `GET /api/browser-task/<taskId>` and report `state`, the
+last `actionLog` entry, and `queueState` if pending. States:
+
+- `pending` — queued; read `queueState` for position. `running` — acting.
+- `awaiting_user` / `final_confirm` — relay rules are Hard rule 3 + the
+  clarify section; here just report the state.
+- `completed` — the daemon already DMed the full `✅ Browser task —
+  report`. Don't re-post; if asked "what did it find?", quote the
+  `report` field verbatim (don't paraphrase).
+- `failed` / `timeout` / `cancelled` / `abandoned` — terminal; the daemon
+  already DMed `🟦 Browser task <id> ended: <state>`. `outcome_detail`
+  carries the reason (e.g. `queue_timeout`, `budget_exceeded`,
+  `tool_loop_detected`) — quote it verbatim.
+
+## Force-stop — "stop" / "cancel" / "abort" / "止めて"
+
+When the user signals stop, find the task (same identification path as
+status), then `POST /api/browser-task/<taskId>/cancel` with optional
+`{"reason":"user_cancel"}`. The daemon aborts the in-flight sub-agent,
+tears down the Chromium context, and writes the terminal state.
+
+- `200` — accepted; `row.state` carries the post-cancel state (often
+  `cancelled`, but a `running` task may briefly stay non-terminal until
+  the SDK loop unwinds — re-read with GET if asked).
+- `404 not_found` — stale `taskId`; re-read with GET.
+- `409 already_terminal` (carries `currentState`) — too late; report the
+  state verbatim.
+
+Do NOT cancel without a clear signal; "wait" is NOT a cancel.
+
+## Navigation is open
+
+There is no positive allowlist or registered-site table. Whatever URL the
+sub-agent navigates to passes three runtime layers: (1) the user-curated
+hostname denylist (Dashboard → Settings → Browser; a hit returns
+`blockedByAllowlist: true` — legacy field name), (2) the hardcoded
+payment-path block (purchases live in `/api/browser-automation/purchase/*`
+with the B-4 token), (3) the network IP CIDR fence (RFC1918, loopback,
+`169.254.x.x`, IPv6 ULA). If the sub-agent reports `blockedByAllowlist` /
+`blockedByPaymentPath`, quote the reason verbatim and point the user at
+`/settings/browser` if a denylist entry is the cause. **Never decline on
+the user's behalf before POSTing — that's the user's call.**
+
+## Scheduling — `scheduleAt` ≠ the `schedule` skill
+
+For "do X at <time>" use `scheduleAt` in this POST — NOT `/api/schedule`.
+The browser-task surface owns its own `agent_schedule` row
+(`task_type:"browser_task"`). The `schedule` skill is the right tool only
+when the user wants to list / modify / cancel pending schedules (which
+surface scheduled browser tasks alongside other rows).

package/agent-assets/skills/context/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context
-description: Load when reading or writing project notes, weekly/monthly summaries, or agent/journal.md. Owns GET/PATCH for context files except today.md and roadmap.md, which use their dedicated skills.
+description: Load when reading or writing project notes, weekly/monthly summaries, or journal/agent.md. Owns GET/PATCH for context files except today.md and roadmap.md, which use their dedicated skills.
 allowed-tools:
   - Bash(curl *)
   - Read
@@ -26,58 +26,48 @@ vault**, not this primary store.
 
 | File | Purpose | Owner | Lock? |
 |---|---|---|---|
-| `today.md` | Today's schedule, tasks, agent log, handoff | See `today` skill | Yes (Morning Routine) |
-| `roadmap.md` | Long-horizon agent action plan + Long-term Plans | See `roadmap` skill | Yes (Roadmap Refresh) |
-| `projects/*.md` | Project state summaries | Any event on material state change | No |
-| `weekly/YYYY-Www.md` | Weekly review snapshots | Friday Weekly Review only (PUT) | No |
-| `monthly/YYYY-MM.md` | Monthly review snapshots | Month-end Monthly Review only (PUT) | No |
-| `rules/*.md` | User-controlled policy files | Explicit user request only | No |
-| `rules/policies/<slug>.md` | Durable management policies captured from DM | `management-policy` skill — **do not write from here** | No |
-| `rules/policies/_index.md` | Readable index of active policies | `management-policy` skill — **do not write from here** | No |
-| `routines/*.md` | Per-cadence check rulebooks | Explicit user request only | No |
-| `user/profile.md` | User identity and preferences | `user-profile` skill — **do not write from here** | No |
-| `user/*.md` | Detailed user dictionary | `user-profile` skill — **do not write from here** | No |
+| `state/today.md` | Today's schedule, tasks, agent log, handoff | See `today` skill | Yes (Morning Routine) |
+| `plans/roadmap.md` | Long-horizon agent action plan + Long-term Plans | See `roadmap` skill | Yes (Roadmap Refresh) |
+| `plans/projects/*.md` | Project state summaries | Any event on material state change | No |
+| `journal/weekly/YYYY-Www.md` | Weekly review snapshots | Friday Weekly Review only (PUT) | No |
+| `journal/monthly/YYYY-MM.md` | Monthly review snapshots | Month-end Monthly Review only (PUT) | No |
+| `policies/*.md` | User-controlled policy files | Explicit user request only | No |
+| `policies/management-captures/<slug>.md` | Durable management policies captured from DM | `management-policy` skill — **do not write from here** | No |
+| `policies/management-captures/_index.md` | Readable index of active policies | `management-policy` skill — **do not write from here** | No |
+| `policies/routines/*.md` | Per-cadence check rulebooks | Explicit user request only | No |
+| `identity/profile.md` | User identity and preferences | `user-profile` skill — **do not write from here** | No |
+| `identity/*.md` | Detailed user dictionary | `user-profile` skill — **do not write from here** | No |
 
 Morning Routine scans roadmap daily and processes matching Preparation
-Timeline rows into `today.md` — see the `roadmap` skill for the full
+Timeline rows into `state/today.md` — see the `roadmap` skill for the full
 entry taxonomy and the morning routine task-flow for the scanning rules.
 
-## projects/*.md
+## plans/projects/*.md
 
-Update on status changes, milestones reached/delayed, or active set changes. Use `GET /api/context/list/projects` to discover files. The source of truth is always the individual `projects/<slug>.md` notes; `_active.base` is only the Obsidian Bases view config, not a narrative summary note.
+Update on status changes, milestones reached/delayed, or active set changes. Use `GET /api/context/list/plans/projects` to discover files. The source of truth is always the individual `plans/projects/<slug>.md` notes; `_active.base` is only the Obsidian Bases view config, not a narrative summary note.
 
-The canonical frontmatter schema is documented in `projects/_index.md`
-(seeded from `agent-assets/templates/projects/_index.md`). The API
+The canonical frontmatter schema is documented in `plans/projects/_index.md`
+(seeded from `agent-assets/templates/plans/projects/_index.md`). The API
 validates only `type: project`, `owner: shared`, `updated`, and an H1
 (`context-frontmatter.ts`). Conventional but unvalidated fields —
 `slug`, `state`, `start`, `due`, `stakeholders`, `next_milestone`,
 `tags` — should still be written for new files because the
-`projects/_active.base` Obsidian view filters on `state`.
+`plans/projects/_active.base` Obsidian view filters on `state`.
 
 ## Project DM-intent detection
 
-DM-driven project state writes are dispatched from
-`message.received.dm.md` / `message.received.dm_first.md` Step 4 via
-the `_partials/dm-intent.project.md` task-flow partial — that partial
-carries the decision tree (existing-vs-new match, decline-marker
-pre-check, no-match confirm sub-flow scheduling, reply branches,
-cross-path cancellation, slug grammar, tie-breakers).
+DM-driven project writes are dispatched by
+`_partials/dm-intent.project.md` (the decision tree — match, decline
+markers, confirm sub-flow, slug grammar, tie-breakers — lives there).
+**This skill is the writer:** it executes the `plans/projects/*.md`
+PUT / PATCH / archive per the API Reference below.
 
-**This skill is the writer.** `projects/<slug>.md` PUT / PATCH / archive
-goes through `/api/context/projects/*` per the API Reference below. The
-partial dispatches; this skill executes the writes.
+## Snapshot files — weekly / monthly / policies / routines
 
-Cross-references previously in this section ("Reply branches",
-"Cross-path cancellation", "Decline-marker reversal", "Tie-breakers",
-"Slug grammar") now live alongside their decision-tree steps inside
-the partial.
-
-## Snapshot files — weekly / monthly / rules / routines
-
-Weekly and monthly review snapshots, the user-controlled `rules/*.md`
-policy files, the built-in `routines/<cadence>.md` rulebooks, custom
-routines under `routines/custom/`, and the agent-private
-`agent/journal.md` all have stable per-file conventions (writer event,
+Weekly and monthly review snapshots, the user-controlled `policies/*.md`
+policy files, the built-in `policies/routines/<cadence>.md` rulebooks, custom
+routines under `policies/routines/custom/`, and the agent-private
+`journal/agent.md` all have stable per-file conventions (writer event,
 verb, frontmatter, retention) documented in the snapshot-files
 reference below.
 
@@ -88,11 +78,12 @@ DM handlers and Hourly Checks should generally not write these files
 
 ## Required frontmatter for guarded files
 
-Full-file writes to `user/*.md`, `rules/*.md`, `projects/*.md`,
-`daily/*.md`, `weekly/*.md`, and `monthly/*.md` must open with the
-matching YAML frontmatter (`type`, `owner`, `updated`) followed by at
-least one H1 heading. Per-glob values and the common rejection
-envelope are in the required-frontmatter reference below.
+Full-file writes to `identity/*.md`, `policies/*.md`,
+`plans/projects/*.md`, `journal/daily/*.md`, `journal/weekly/*.md`, and
+`journal/monthly/*.md` must open with the matching YAML frontmatter
+(`type`, `owner`, `updated`) followed by at least one H1 heading.
+Per-glob values and the common rejection envelope are in the
+required-frontmatter reference below.
 
 {{> ref:required-frontmatter }}
 
@@ -101,7 +92,7 @@ envelope are in the required-frontmatter reference below.
 The full `/api/context/*` surface — read / write / list / lock /
 archive / restore / health / repair / action-log — is organised by
 operation in the reference below. Add `X-Lock-Id` on every PUT / PATCH
-to `today.md` (`<today_write_lock_id>`) or `roadmap.md`
+to `state/today.md` (`<today_write_lock_id>`) or `plans/roadmap.md`
 (`<roadmap_write_lock_id>`) when the matching lock-id tag is in your
 context.
 

package/agent-assets/skills/context/curation.json

@@ -8,14 +8,14 @@
       "human_label": "File responsibilities",
       "description": "Which file owns which area of the context tree (today, roadmap, projects, weekly, rules, user)",
       "scope_paths": [
-        "today.md",
-        "roadmap.md",
-        "projects/*.md",
-        "weekly/*.md",
-        "monthly/*.md",
-        "rules/*.md",
-        "user/*.md",
-        "agent/*.md"
+        "state/today.md",
+        "plans/roadmap.md",
+        "plans/projects/*.md",
+        "journal/weekly/*.md",
+        "journal/monthly/*.md",
+        "policies/*.md",
+        "identity/*.md",
+        "journal/agent.md"
       ]
     },
     {
@@ -25,12 +25,12 @@
       "human_label": "Required frontmatter for guarded files",
       "description": "Per file-glob: required + conventional frontmatter keys",
       "scope_paths": [
-        "projects/*.md",
-        "user/*.md",
-        "rules/*.md",
-        "weekly/*.md",
-        "monthly/*.md",
-        "daily/*.md"
+        "plans/projects/*.md",
+        "identity/*.md",
+        "policies/*.md",
+        "journal/weekly/*.md",
+        "journal/monthly/*.md",
+        "journal/daily/*.md"
       ]
     }
   ]