atris 3.34.0 → 3.36.0

package/atris/skills/improve/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: improve
-description: "Run one RL improvement tick on the workspace via POST /api/improve. Ships one verifiable change, scores it, writes the scorecard. The thing you pay for. Triggers on: improve, make this better, ship one thing, run a tick, get smarter."
-version: 1.0.0
+description: "Run one verified, scored improvement tick and write its receipt. Use when the user asks to improve, make this better, ship one thing, run a tick, or get smarter. `atris improve` alone shows metabolism vitals; use `atris improve tick` to ship work."
+version: 1.1.0
 tags:
   - rl
   - improve
@@ -12,74 +12,94 @@ tags:
 
 # /improve
 
-Runs one improvement tick on the workspace. Calls `POST /api/improve` on the backend, which plans one task, builds it, verifies it, and scores it. Returns what shipped + the reward. Writes the scorecard locally.
+Run one improvement tick on the workspace. A successful tick ships one result, passes a real verifier, receives a score, and writes a machine-readable scorecard.
 
-This is the product. The thing the user pays for. One call, one verifiable result.
+One call means one verifiable result. Never turn one invocation into a hidden batch.
 
-## How it works
+## Command contract
 
+`atris improve` alone shows the self-improvement metabolism vitals. It does not ship a change.
+
+Use the explicit `tick` subcommand when the user asks for improvement work:
+
+```bash
+atris improve tick                    # one full tick: plan, build, verify, score
+atris improve tick --json             # the same tick as machine-readable output
+atris improve tick plan               # plan only; no change or receipt
+atris improve tick --dry-run          # execute without committing; no shipping receipt
+atris improve tick --no-fallback      # report API failure instead of running locally
+atris improve history                 # reward trend, credits, and pass rate
+atris improve                         # vitals only
+atris improve --json                  # vitals only as JSON
 ```
-/improve
-  → POST /api/improve { workspace: ".", mode: "full" }
-  → backend picks a task, plans, builds, reviews, verifies
-  → returns { task, reward, files_changed, verify_pass, summary }
-  → CLI writes scorecard to .atris/presidio/scorecards.md
-  → CLI reports result to user
-```
 
-The inference is Claude Code (or whatever model the backend uses). The environment is the folder. The endpoint is the bridge.
+## Run one tick
+
+1. Run `atris improve tick`, adding `--json` only when structured output is useful.
+2. Inspect the returned source, task summary, verifier result, reward, files, and receipt path.
+3. Count the tick only when `ok` is true, verification passed, and the scorecard was written.
+4. Report what shipped and the exact verifier result. If the tick fails, report the failure and stop.
+
+For a paid API tick, the CLI:
 
-## On invoke
+1. Loads credentials with `utils/auth.loadCredentials`.
+2. Calls `POST /api/improve` with the workspace, mode, model, and dry-run setting.
+3. Lets the backend plan, build, verify, score, and bill the successful tick.
+4. Writes the normalized receipt to `.atris/state/scorecards.jsonl` and the human trail to the daily Atris journal.
 
-Run the CLI command — it does the whole tick (auth, the credit-metered call, scorecard, fallback):
+The full response may omit the billed credit count. In that case the CLI reports that billing happened server-side instead of inventing a number.
+
+## Local fallback
+
+Local fallback is allowed when there is no login, the backend is unreachable, or the hosted backend cannot access the local workspace path. The CLI runs this exact bounded command internally:
 
 ```bash
-atris improve            # one full tick: plan → build → verify → score (deducts credits)
-atris improve plan       # show the plan only, change nothing
-atris improve --json     # machine-readable result (this is what the member loop consumes)
-atris improve --no-fallback   # fail loudly instead of running a local tick when the backend is down
+atris mission run --due --headless --max-ticks 1 --complete-on-pass --json
 ```
 
-Under the hood `atris improve` (`commands/improve.js`):
+The local result succeeds only when all of these are true:
 
-1. Loads the auth token via `utils/auth.loadCredentials`
-2. `POST /api/improve { workspace, mode, model }` via `utils/api.apiRequestJson`
-3. The backend plans, builds, runs the verify command, scores it, and **deducts Atris credits per successful tick** (`bill_tick`)
-4. Writes a per-tick scorecard row to `.atris/state/scorecards.jsonl` (the receipt the brain ledger counts)
-5. Falls back to a local autopilot tick **only** when you are not logged in or the backend is unreachable — a real error (insufficient credits, server error) is reported, never silently retried
+1. Exactly one mission tick ran.
+2. A headless worker actually ran; caller-session and no-worker placeholders are rejected.
+3. The mission verifier passed.
+4. The scorecard and journal receipt were written.
 
-The full-mode response does not echo `credits_deducted` (credits are still billed server-side), so the CLI shows "billed server-side" when the count is absent. To call the endpoint directly instead of the command, `POST /api/improve` with `{ workspace, mode, model }`.
+A verified local tick earns the conservative local reward of `+1` and deducts no credits. No due headless mission, a skipped worker, a failed or missing verifier, or a receipt write failure makes the improve command fail without a reward.
 
-## Modes
+Do not silently fall back for answerable API failures such as insufficient credits, unrelated authorization failures, or server errors.
 
-- `full` — plan, build, review, verify (default)
-- `plan` — just pick the task and show what it would do
-- `dry_run` — run everything but don't commit
+## Expected output
 
-## Fallback
+User says: "Improve this once."
 
-If the backend is unreachable (no auth, no network, localhost not running), fall back to local mode: run `atris autopilot --auto --iterations=1` instead. Same loop, just local inference via `claude -p` subprocess. Report that it ran locally.
+Action: run `atris improve tick`.
 
-## Output
+Expected shape:
 
-```
+```text
 improved.
+  task:    fixed the stale wiki reference
+  verify:  pass
+  reward:  4
+  files:   atris/wiki/auth-flow.md
+  scorecard: .atris/state/scorecards.jsonl
+```
 
-  task:    fixed the stale wiki ref in auth-flow.md
-  verify:  pass (npm test, 143/143)
-  reward:  +4
-  files:   atris/wiki/briefs/auth-flow.md
-  time:    47s
+For local fallback, the first line is `improved (local fallback).` and the report still names the task, passing verifier, reward, and scorecard.
 
-  scorecard updated.
-```
+## Failure handling
+
+- If verification fails or is missing, halt honestly and write a durable lesson. Do not claim improvement.
+- If the command reports no due headless mission, stop; do not manufacture busywork or a scorecard.
+- If the API returns insufficient credits or another answerable error, report it without a local retry.
+- If the workspace is dirty, preserve existing changes. Use an isolated worktree for manual follow-up fixes.
+- If a worker lands work but the outer receipt fails, report the landed commit separately and do not count the improve tick.
 
 ## Rules
 
 - One tick only. Never batch.
-- Always verify. No reward without a check.
+- No reward without a passing verifier.
 - Show what shipped, not what was attempted.
-- Write the scorecard. This is the receipt.
-- If verify fails, halt honestly and write a lesson.
-- Fallback to local if backend is unreachable. Never error silently.
+- A scorecard is required for success.
+- Preserve user work and unrelated changes.
 - The user pays because something real happened. Never fake it.

package/atris/skills/render-cli/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: render-cli
+description: Use the Render.com CLI v2.x (`render`) to inspect Render services, check CLI auth, list services and deploys, trigger deploys when explicitly requested, and view logs. Use when an agent needs Render CLI commands, non-interactive flags, deploy status polling, or service auto-deploy checks.
+version: 1.0.0
+tags:
+  - render
+  - deploy
+  - cli
+---
+
+# Render CLI
+
+Use the `render` binary to manage Render services, deploys, logs, and sessions from the terminal. Treat it like a production-control CLI: read first, parse JSON, and only create or mutate resources when the operator explicitly asked for that action.
+
+## Agent defaults
+
+Always add these flags for agent-safe commands:
+
+- `--output json` for parseable output.
+- `--confirm` to skip confirmation prompts.
+
+The CLI defaults to interactive mode and can hang an agent if a command prompts. If a command is intended to run unattended, include both flags unless the CLI help says the mode is interactive-only.
+
+## Auth
+
+Check the active login before assuming access:
+
+```bash
+render whoami --output json --confirm
+```
+
+If the user is not logged in, ask them to complete:
+
+```bash
+render login
+```
+
+`render login` uses the dashboard/browser login flow, so do not run it in an unattended automation loop.
+
+## Services
+
+List services in the active workspace:
+
+```bash
+render services --output json --confirm
+```
+
+Use the returned service `id` as `<service-id>` in deploy and log commands. When a push to Git did not deploy, inspect the service JSON for `autoDeploy`; it may be disabled for that service.
+
+## Deploys
+
+Trigger a deploy only when the operator explicitly asks for a real deploy:
+
+```bash
+render deploys create <service-id> --output json --confirm
+```
+
+Watch deploy state by polling:
+
+```bash
+render deploys list <service-id> --output json --confirm
+```
+
+Common deploy statuses include `queued`, `build_in_progress`, `update_in_progress`, `live`, and `failed`. Treat `live` and `failed` as terminal states for ordinary deploy monitoring.
+
+## Logs
+
+Query recent logs for a service:
+
+```bash
+render logs --resources <service-id> --limit 100 --output json --confirm
+```
+
+For a live tail, use:
+
+```bash
+render logs --resources <service-id> --tail --confirm
+```
+
+The CLI help says `--tail` streams only in interactive mode, so prefer bounded JSON log queries for automated agents and use live tail only when a long-running interactive stream is acceptable.
+
+## Gotchas
+
+- The CLI is interactive by default; `--confirm` prevents confirmation prompts from blocking the agent.
+- `--output json` makes service, deploy, and log output machine-readable.
+- In non-interactive log mode, `--resources <service-id>` is required.
+- Git pushes do not guarantee deploys. Check `autoDeploy` in the service JSON before assuming push-to-git should deploy.
+- Do not use placeholder IDs in real commands. Resolve a service ID from `render services --output json --confirm` first.

package/atris/skills/youtube/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: youtube
 description: "Process YouTube videos — extract insights, answer questions, store as knowledge. 5 credits per video. Triggers on: youtube, video, process video, watch this, learn from video."
-version: 2.2.0
+version: 2.3.0
 tags:
   - youtube
   - research
@@ -13,6 +13,15 @@ tags:
 
 Process any YouTube video through Atris transcript-first analysis. The CLI extracts local captions with timestamps when available, sends that transcript to Atris, and falls back to cloud video processing when captions are unavailable or unusable. 5 credits per video, refunded if processing fails.
 
+## Route first: learning vs product
+
+Two rails process YouTube videos — pick before running anything:
+
+- **Learning / work rail** → use the `alpha-learn` skill (ytnotes). Local yt-dlp + grok, zero credits, podcastnotes-style notes, tweet-feed output, `[claimable]` entries in today's journal for other agents. Use this when the goal is to LEARN from a video or mine it for Atris work.
+- **Product rail** → this skill (`atris youtube process`). Credits-billed, stores knowledge in the Atris backend, customer-facing path. Use this when a customer/agent needs the video stored as Atris knowledge or answered via the API.
+
+If the user says "learn from", "notes on", "alpha", or "rabbit hole" → alpha-learn. If they say "process", "store", "add to knowledge" → this skill.
+
 ## Bootstrap (ALWAYS Run First)
 
 ```bash

package/atris.md

@@ -47,12 +47,14 @@ Before changing anything, state:
 - what happens if it fails
 
 Then:
+- when you begin work in a repo that has no `atris/` folder, run `npx -y atris init` before anything else, then read `atris/atris.md`
 - do not execute if another agent owns the same task or files
 - do not call something complete without verification
 - land or reap: work is not done until it is merged to the base branch or reaped; if you make a branch or worktree, you merge it or delete it before you stop. Run `atris land` to see limbo; anything past 7 days gets salvaged to `.atris/salvage/` and deleted by `atris land --reap`.
 - do not take irreversible actions without approval from the human
 - do not hide state outside markdown, logs, diffs, or the journal
 - do not edit the rules that judge you: the reward config, the authority policy, or this file
+- do not judge your own work: certification and acceptance require a review pass from an actor other than the builder; the tick's independent re-run counts, you do not (guarded)
 
 If you cannot honor these rules, stop, write why in the journal, and ask the human before continuing.
 
@@ -88,12 +90,14 @@ The same discipline for words. Output stays sharp no matter how bloated the cont
   - "Missions survive everything: one engine starts the work, another picks it up cold, a third lands it. Work is no longer tied to a chat window, a session, or a vendor."
   - "The system reports in plain English: one daily message with what landed, what waits on you, and who should own what's next. One person can supervise many projects."
 - **Fit the screen.** An operator-facing report shows three results, air between them, and holds the rest on ask. No scrolling: reading it is one glance, and the reader asks for more if they want more.
+- **Human surfaces are gated.** Anything rendered for the operator (brief, digest, boot) goes through the operator-voice translator and a deterministic jargon gate; raw ids, commands, paths, and test tallies never reach a page. A gate violation is a build error, not a style note.
+- **Interview the fuzz.** When the operator hands off a fuzzy build ("make me the best X", "yeah ok this is my thought, go make it"), do not ask open questions and do not dispatch as-is. Offer 2-3 named interpretations with a recommendation ("best could mean capture, resurfacing, or closure: I'd bet resurfacing, right?") so the operator confirms or corrects in five words. Repeat until the brief fits one screen (goal, why now, done-looks-like, open risks), show the brief, then dispatch. The interview lends the operator a structure to think in; the sharpened brief is what makes every downstream lap cheap.
 
 `expected`: this is how an Atris agent writes and builds. Shipping slop or rambling is a failure smell, same as drift or a stale task.
 
 ## the ladder
 
-Six primitives, one sentence each. Every agent in every repo holds this model:
+Six primitives, one sentence each:
 
 - **The Mission** (MISSION.md): the enduring purpose. Never ends. Sits at the top and helps members pick goals.
 - **Goals** (endgame, member goals): direction derived from the Mission. A goal points; it does not commit.
@@ -106,7 +110,7 @@ In one line: the Mission anchors, goals point, a mission run commits, tasks prov
 
 Never conflate the two things called "mission": the Mission is permanent purpose; a mission run is a bounded commitment. An agent that mistakes a run for the Mission never stops working on it; one that mistakes the Mission for a run tries to complete it.
 
-Drift smells: a member goal tracing to no Mission is freelancing; a goal that never becomes a mission run is a wish; a run with no goal above it is busywork; a loop deciding what "done" means owns the wrong axis.
+Drift smells: a member goal tracing to no Mission is freelancing; a goal that never becomes a mission run is a wish; a run with no goal above it is busywork; a loop deciding what "done" means owns the wrong axis. A loop may run without a member, never without a witness: every loop names an owner, and its failure escalates to something with judgment.
 
 ## task source of truth