failproofai 1.0.1-beta.1 → 1.0.1

package/.next/standalone/docs-old/getting-started.mdx

@@ -0,0 +1,201 @@
+---
+title: Getting started
+description: "Install failproofai, enable policies, and let your agents run reliably"
+icon: rocket
+---
+
+## Requirements
+
+- **Node.js** >= 20.9.0
+- **Bun** >= 1.3.0 (optional - only needed for building from source)
+
+---
+
+## Installation
+
+<CodeGroup>
+
+```bash npm
+npm install -g failproofai
+```
+
+```bash bun
+bun add -g failproofai
+```
+
+</CodeGroup>
+
+---
+
+## Quick start
+
+<Steps>
+  <Step title="Enable policies">
+    Policies are rules that run before and after every agent tool call. They catch destructive commands, secret leakage, and other failure modes before they cause damage.
+
+    ```bash
+    failproofai policies --install
+    ```
+
+    This writes hook entries into your installed agent CLIs (Claude Code's `~/.claude/settings.json`, OpenAI Codex's `~/.codex/hooks.json`, GitHub Copilot CLI's `~/.copilot/hooks/failproofai.json`, Cursor Agent's `~/.cursor/hooks.json`, OpenCode's generated plugin shim at `~/.config/opencode/plugins/failproofai.mjs` plus a registration entry in `~/.config/opencode/opencode.json`'s `plugin` array, Pi's `~/.pi/agent/settings.json`, Hermes's `~/.hermes/config.yaml`, OpenClaw's `~/.openclaw/openclaw.json`, Factory Droid's `~/.factory/hooks.json`, Devin CLI's `~/.config/devin/config.json`, Antigravity CLI's `~/.gemini/config/hooks.json`, or Goose's auto-discovered plugin dir at `~/.agents/plugins/failproofai/hooks/hooks.json`). When more than one is present you'll be prompted; pass `--cli claude codex copilot cursor opencode pi hermes openclaw factory devin antigravity goose` (any subset) to skip the prompt.
+
+    GitHub Copilot CLI, Cursor Agent, OpenCode, and Pi support are **beta** — install with `--cli copilot`, `--cli cursor`, `--cli opencode`, or `--cli pi`. Hermes (hermes-agent, a Slack/Telegram gateway) installs user-scope with `--cli hermes` and is **also** an offline audit source. OpenClaw (openclaw gateway, a self-hosted multi-channel assistant) installs user-scope with `--cli openclaw` — enforcement runs through its in-process plugin hooks (`before_agent_finalize` is a real turn-end gate, so the `require-*-before-stop` builtins enforce) — and is **also** an offline audit source. Factory Droid (`droid`) installs with `--cli factory` (user + project scope) and is **also** an offline audit source. Devin CLI (`devin`, Cognition) installs with `--cli devin` (user + project scope) and is **also** an offline audit source. Antigravity CLI (`agy`) installs with `--cli antigravity` (user + project scope) and is **also** an offline audit source. Goose (codename goose, Block) installs with `--cli goose` (user + project scope) — the installer just drops a plugin dir at `~/.agents/plugins/failproofai/` that Goose auto-discovers, and it is **also** an offline audit source.
+
+    ```bash
+    failproofai policies --install --scope project
+    failproofai policies --install --cli codex --scope project
+    failproofai policies --install --cli copilot --scope project
+    failproofai policies --install --cli cursor --scope project
+    failproofai policies --install --cli opencode --scope project
+    failproofai policies --install --cli pi --scope project
+    failproofai policies --install --cli hermes --scope user
+    failproofai policies --install --cli openclaw --scope user
+    failproofai policies --install --cli factory --scope project
+    failproofai policies --install --cli devin --scope project
+    failproofai policies --install --cli antigravity --scope project
+    failproofai policies --install --cli goose --scope project
+    failproofai policies --install block-sudo block-rm-rf sanitize-api-keys
+    ```
+  </Step>
+  <Step title="Verify">
+    ```bash
+    failproofai policies
+    ```
+
+    Shows every policy, whether it's enabled, and any configured parameters.
+  </Step>
+  <Step title="Launch the dashboard">
+    ```bash
+    failproofai
+    ```
+
+    Opens a local dashboard at `http://localhost:8020` where you can browse sessions, inspect tool calls, and manage policies.
+  </Step>
+  <Step title="Run your agent">
+    Start Claude Code as usual. If the agent tries something risky, failproofai intercepts it automatically. Leave it running unattended and review what happened in the dashboard.
+  </Step>
+</Steps>
+
+---
+
+## How policies work
+
+Every time an agent runs a tool, Claude Code calls failproofai as a subprocess:
+
+```text
+Claude Code  →  failproofai --hook PreToolUse  →  reads stdin JSON
+                                                 evaluates policies
+                                                 writes decision to stdout
+```
+
+Each policy returns one of three decisions:
+
+- **allow** - the agent proceeds normally
+- **deny** - the action is blocked, the agent is told why
+- **instruct** - extra context is added to the agent's prompt
+
+<Note>
+Policies run in your local process. Nothing is sent to a remote service.
+</Note>
+
+---
+
+## Set up team policies with convention-based policies
+
+The fastest way to establish quality standards across your team is the `.failproofai/policies/` convention. Drop policy files into this directory and they're loaded automatically — no flags, no config changes, no install commands.
+
+<Steps>
+  <Step title="Create the policies directory">
+    ```bash
+    mkdir -p .failproofai/policies
+    ```
+  </Step>
+  <Step title="Add policy files">
+    Copy the starter examples or write your own:
+
+    ```bash
+    cp node_modules/failproofai/examples/convention-policies/*.mjs .failproofai/policies/
+    ```
+
+    Or create a new one:
+
+    ```js
+    // .failproofai/policies/team-policies.mjs
+    import { customPolicies, allow, deny, instruct } from "failproofai";
+
+    customPolicies.add({
+      name: "test-before-commit",
+      match: { events: ["PreToolUse"] },
+      fn: async (ctx) => {
+        if (ctx.toolName !== "Bash") return allow();
+        if (/git\s+commit/.test(ctx.toolInput?.command ?? "")) {
+          return instruct("Run tests before committing.");
+        }
+        return allow();
+      },
+    });
+    ```
+  </Step>
+  <Step title="Commit to git">
+    ```bash
+    git add .failproofai/policies/
+    git commit -m "Add team quality policies"
+    ```
+
+    Every team member who has failproofai installed picks up these policies automatically. No per-developer setup needed.
+  </Step>
+</Steps>
+
+<Tip>
+Commit `.failproofai/policies/` to your repo so the whole team shares the same standards. As your team discovers new failure modes, add policies and push — everyone gets the update on their next `git pull`. Over time these policies become a living quality standard that keeps improving.
+</Tip>
+
+---
+
+## Data storage
+
+All configuration and logs stay on your machine:
+
+| Path | What it stores |
+|------|----------------|
+| `~/.failproofai/policies-config.json` | Global policy config |
+| `~/.failproofai/policies/` | Your own policies — drop `*-policies.mjs` in, no config needed |
+| `~/.failproofai/policies/cloud-policies/` | Policies deployed to this machine by your organisation |
+| `~/.failproofai/hook-activity/` | Hook execution history (paged JSONL) |
+| `~/.failproofai/logs/` | Debug logs for custom hook errors |
+| `.failproofai/policies-config.json` | Per-project config (committed) |
+| `.failproofai/policies-config.local.json` | Personal overrides (gitignored) |
+
+---
+
+## Uninstalling
+
+```bash
+failproofai policies --uninstall
+```
+
+Removes hook entries from `~/.claude/settings.json`. Config files in `~/.failproofai/` are kept.
+
+---
+
+## Next steps
+
+<CardGroup cols={2}>
+
+<Card title="Configuration" icon="gear" href="/configuration">
+  Scopes and config file format
+</Card>
+
+<Card title="Built-in policies" icon="shield" href="/built-in-policies">
+  All 26 policies with parameters
+</Card>
+
+<Card title="Custom policies" icon="code" href="/custom-policies">
+  Write your own policies in JavaScript
+</Card>
+
+<Card title="Agent monitor" icon="chart-line" href="/dashboard">
+  Monitor sessions and review policy activity
+</Card>
+
+</CardGroup>

package/.next/standalone/docs-old/he/agenteye/alerts.mdx

@@ -0,0 +1,63 @@
+---
+title: "התראות"
+description: "גלה ברגע שמשהו חוצה את הגבול שלך, בערוץ שהצוות שלך כבר צופה בו, במקום לשמוע על זה מלקוח."
+---
+
+
+גלה ברגע שמשהו חוצה את הגבול שלך, בערוץ שהצוות שלך כבר צופה בו, במקום לשמוע על זה מלקוח. הגדר כלל פעם אחת ו-Failproof AI Observability בודק אותו לפי לוח זמנים, ואז שולח לך התראה בדוא"ל, Slack, webhook, או ישירות בלוח הבקרה.
+
+![עמוד ההתראות: רשת של כרטיסי כללי התראה, כל אחד מציג את ההגדרה שלו, חלון ההערכה, ערוצים, ותג חומרה של מידע, אזהרה או קריטי](/agenteye/images/alerts.png)
+*כל כלל התראה בהצצה: מה הוא מוקד, בכמה תדירות, לאן זה שולח התראות, ועד כמה זה דחוף.*
+
+## קבל ידיעה על בעיות לפני המשתמשים שלך
+
+הפסק להחדש את לוח הבקרה בתקווה לתפוס רגרסיה. השתמש בהתראה בכל פעם שיש אות שתרצה לשמוע עליה גם כשאף אחד לא מביט, והנח אותה במקום שבו אתה כבר נמצא:
+
+- **דוא"ל**, למי שצריך לדעת.
+- **Slack**, הודעה עשירה עם כפתור שקופץ ישר לתקרית.
+- **Webhook**, JSON POST ל-PagerDuty, Opsgenie, או לנקודת הקצה שלך, עם חתימה אופציונלית כדי שהמקבל יוכל לסמוך עליה.
+- **בלוח הבקרה**, שקט בעיצוב, כשאתה מכוונן כלל ולא רוצה עדיין להתריע לאיש.
+
+צרף כל שילוב לכלל יחיד, וחומרתו (מידע, אזהרה או קריטי) נשארת עם זה כדי שהחשוב נראה חשוב.
+
+## בנה את הכלל בטופס, לא ב-JSON
+
+אתה מתאר מה "שבור" אומר בטופס, ו-Failproof AI Observability כותב את הכלל הבסיסי בשבילך. מפרט ה-JSON הוא רק מה שהטופס הזה מייצר בעמקי המערכת, כך שאתה יכול לקרוא אותו כדי להבין כלל אבל בדרך כלל לא תקליד אותו.
+
+![טופס ההתראה החדשה: שם ותיאור, כפתור הפעלה, ובוררי הגדרה המציעים סף מטרי, SQL מותאם אישית, ציון הערכה, eval מורכב, ותנאים לכל אירוע](/agenteye/images/alert-new.png)
+*בחר הגדרה והטופס מחליף לשדות הנכונים; שמור כותב את הכלל.*
+
+הנתיב הטוב הוא מהיר: תן לו שם, בחר **הגדרה** (מה לצפות בו), קבע **סף וחלון** (כמה רע, על פני כמה זמן), צרף לפחות ערוץ **אחד**, ואז **שמור** ולחץ על **בדיקה** כדי לשלוח התראה סינתטית ולאשר שכל יעד חוברה. בעמקי המערכת זה יוצר spec קטן כמו:
+
+```json
+{ "metric": "p95_latency_ms", "op": ">", "value": 5000, "window_secs": 900 }
+```
+
+אתה לא מוגבל לסוג אות אחד. בחר בהגדרה שמתאימה לאופן שבו אתה חושב על הכשל:
+
+| הגדרה | משדרת כאשר |
+|---|---|
+| **סף מטרי** | מטרי קבוע מראש (שיעור שגיאה, p95 או p99 latency, ספירות אירוע או שגיאה, הוצאות token) חוצה את הגבול שלך על פני חלון |
+| **SQL מותאם אישית** | השאילתה קריאה בלבד שלך מחזירה שורה, או ערך שהיא מחשבת חוצה סף |
+| **ציון הערכה** | ממוצע ציון מעריך (נניח, hallucination) חוצה סף |
+| **Eval מורכב** | מספר בדיקות ציון משולבות עם any, all, או at-least-N logic, כדי לתפוס רגרסיה שמופיעה רק על פני ציונים |
+| **לכל אירוע** | אירוע תואם יחיד נוחת: agent ספציפי, סוג שגיאה ספציפי, או substring הודעה |
+
+כבר בעיניים על כשל בעמוד ה-[Errors](/he/agenteye/error-tracking)? כל שורה שם יש לה כפתור **+ alert** שפותח את אותו טופס עם מילוי מראש כדי לתפוס את הכשל המדויק הזה שוב, כך שהתקרית שזה עתה טיפלת בה הופכת לאחד שישדר לך בפעם הבאה.
+
+**איפה למצוא אותו:** התראות נמצאות ב-`/<org-slug>/alerts`. יצירה, עריכה, מחיקה, ובדיקת כללים דורשים **`alerts:write`**; `alerts:read` מספיק להסתכלות. בוררי הנמענה מפרטים את חברי הארגון שלך בשם, כך שתוכל להתריע לאדם מבלי להשאיר את הטופס.
+
+## התריע אותי רק כשזה אמיתי
+
+מדידה רעה אחת לא צריכה להעיר אותך. מסנן הרעש **M של N** שולט בכמה מהבדיקות האחרונות החייבות להיכשל לפני שההתראה בעצם משדרת אותך. קבע אותו ל-**3 מ-5** והכלל משדר רק לאחר שהוא חרג שלוש מחמש הבדיקות האחרונות שלו, כך שאות רועד מפסיק לבכות לזئב; השאר את ברירת המחדל **1 מ-1** כדי להשדר על החרגה הראשונה. אתה גם בוחר כמה לעתים קרובות הכלל פועל, מערכות הגדרות של 1m, 5m, 15m, ו-1h, תואמות לאופן שהאות באמת זז.
+
+## מה קורה כשהתראה משדרת
+
+הפרה פותחת **תקרית** ומשדרת את הערוצים שלך פעם אחת. משם הצוות שלך מכיר בה, מקצה בעלים, דן בה, ופותר אותה, הכל מול רקורד נקי ומיוחסו. לזרימת העבודה של טריאז 'הזו יש בית משלו: ראה [Incidents](/he/agenteye/incidents).
+
+## קשור
+
+- [Incidents](/he/agenteye/incidents): עקוב אחר התראה משדרת מפתח לממומנע לנפתר.
+- [Error tracking](/he/agenteye/error-tracking): קבץ כשלי agent והעלה אחד להתראה בלחיצה.
+- [Dashboards](/he/agenteye/dashboards): צפה בלוחות המשותפים שהספים שאתה משדר עליהם מגיעים מהם.
+- [CLI and agents](/he/agenteye/cli-and-agents): צור התראות וack תקריות מהטרמינל שלך, או script אותן ל-CI.

package/.next/standalone/docs-old/he/agenteye/api-keys.mdx

@@ -0,0 +1,279 @@
+---
+title: "מפתחות API"
+description: "מפתחות API שולטים על מי ומה יכול להגיע לשרת Failproof AI Observability שלך, כך שקולקטור יכול לשלוח אירועים מבלי להשיג אי פעם הרשאות קריאה או admin."
+---
+
+מפתחות API שולטים על מי ומה יכול להגיע לשרת Failproof AI Observability שלך, כך שקולקטור יכול לשלוח אירועים מבלי להשיג אי פעם הרשאות קריאה או admin. כל מפתח נושא הרשאה אחת או יותר, וכל הרשאה שולטת במסלולי שרת ספציפיים; אתה מעניק רק את אלה שעבודה זקוקה להם. רוב ההפעלות יוצרות רק שלוש סוגי מפתחות.
+
+## 3 המפתחות שרוב ההפעלות צריכות
+
+| מפתח | הרשאות | מי משתמש בו |
+|---|---|---|
+| מפתח קולקטור | `events:add` | ה-`agenteye-collector` על כל מכונת אג'נט, כדי לשלוח אירועים. |
+| מפתח קריאה Dashboard | `events:read`, `keys:read` | אופרטור קריאה בלבד או אינטגרציה החוקרת נתונים מבלי לשנות אותם. |
+| מפתח admin Bootstrap | כל ההרשאות | האופרטור שמעלה את ההופעה לראשונה (ו-Dashboard). זרוע מתוך משתנה הסביבה `ADMIN_KEY`. ראה [מפתח admin Bootstrap](#bootstrap-admin-key). |
+
+התחל כאן. פנה לקטלוג ההרשאה המלא למטה רק כשאתה צריך מפתח בהיקף מותאם וצר יותר. ראה גם [פריסת מפתחות מומלצת](#recommended-key-layout) ו[יצירת מפתחות](#creating-keys).
+
+---
+
+## הרשאות
+
+השרת אוכף קטלוג קבוע של הרשאות; כל אחת שולטת במסלולי HTTP ספציפיים. **מפתח admin** מחזיק בכל אחת מהן; מפתח בהיקף מחזיק בתת-הקבוצה שאתה מעניק ביצירה. מחרוזות הרשאה לא ידועות נדחות כאשר מפתח נוצר.
+
+> **הערה:** שתי הרשאות תקפות הן dashboard-only בלבד ולא יכולות להיות ממנויות למפתח API: `orgs:admin` (ניהול instance, שהוא רק לאופרטור) ו`keys:update`. בקשה ל-`POST /keys` או `PATCH /keys/:id` שמנסה להעניק אחת מהן נדחית ב-HTTP 422. ראה את שורת `keys:update` למטה כדי להבין למה מפתח bearer עשוי ליצור מפתחות אך אף פעם לא לערוך אותם.
+
+### הנגשת אירועים וחקירה
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `events:add` | `POST /events` | הנגשת אצווות של אירועים מקולקטור. ההרשאה היחידה שקולקטור צריך. |
+| `events:read` | `GET /events`, `GET /events/latency_aggregate`, `GET /events/environments`, `GET /events/models`, `GET /sessions/:session_id/export` | חקירת אירועים, רשימת הסביבות הידועות, רשימת מזהי המודלים שנראו בנתונים (בשימוש בתצוגת Models ובמסננים של מודלים), חישוב ההיקף latency המניע את heat-map / percentile band, וייצוא session כ-JSONL. נקודות קצה של facet של סרגל ההסנן המשותף `GET /events/environments` ו`GET /events/agent_ids` ניתנות להשגה ב-**או** `events:read` **או** `evaluations:read`, כך שעמוד ה-sessions (gated `evaluations:read`) משתמש ב-facet per-org זהה. `GET /events/models` אינו אחד מהם: הוא דורש `events:read`, כך שעקרון שמחזיק רק ב-`evaluations:read` מקבל 403 ממנו. |
+
+### Sessions והערכות
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `evaluations:read` | `GET /sessions`, `GET /evaluations`, `GET /evaluations/aggregate`, `GET /evaluations/environments`, `GET /evaluation-jobs` | רשימת sessions, קריאת תוצאות הערכה, בריאות eval מגוללת בשימוש ב-dashboards, וחווקרת ה-evaluation-job worker. |
+| `evaluations:trigger` | `POST /sessions/:session_id/re-evaluate` | ערוך ידנית re-evaluation לסשן שהסתיים. |
+
+### Dashboards
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `dashboards:read` | `GET /dashboards`, `GET /dashboards/:id`, `GET /dashboards/:id/tiles` | רשימת dashboards, טעינת אחד, וקריאת הplates שלו. |
+| `dashboards:write` | `POST /dashboards`, `PUT /dashboards/:id`, `POST /dashboards/:id/tiles`, `PUT /dashboards/:id/tiles/:tile_id`, `DELETE /dashboards/:id/tiles/:tile_id`, `PUT /dashboards/:id/tiles/layout` | יצירה ועריכת dashboards, הוספה / עריכה / הסרת tiles, והסדרה מחדש של grid ה-tile. |
+| `dashboards:delete` | `DELETE /dashboards/:id` | מחק dashboard שלם (מחיקה ברמת tile חיה תחת `dashboards:write`). |
+
+### שאילתות שמורות (SQL composer)
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `queries:read` | `GET /queries`, `GET /queries/:id`, `GET /queries/schema` | רשימת שאילתות שמורות, טעינת אחת, וביקורת הסכימה read-only שה-composer מכוון אליה. |
+| `queries:write` | `POST /queries`, `PUT /queries/:id` | יצירה ועריכת שאילתות שמורות. SQL עדיין מנוהל דרך אותו role read-only בדיוק ובדיקות SQL שמורות כמו קריאה `queries:run`. |
+| `queries:delete` | `DELETE /queries/:id` | מחק שאילתה שמורה. |
+| `queries:run` | `POST /queries/run` | בצע SQL שמור או ad-hoc נגד ה-role read-only בשימוש ה-composer. |
+
+### AI assistant
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `agent:use` | `GET /agent/conversations`, `POST /agent/conversations`, `GET /agent/conversations/:id`, `PATCH /agent/conversations/:id`, `DELETE /agent/conversations/:id`, `PUT /agent/conversations/:id/messages` | דוברה עם ה-AI assistant וניהול שלך שלך (private) שיחות. נדרש ב-**user** כדי לראות את ה-assistant dock; המפתח שלו עצמו של ה-assistant הוא `dashboard-assistant` וזריעה נפרדת (ראה למטה). |
+
+### מפתחות API
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `keys:create` | `POST /keys` | צור מפתח API בהיקף חדש. **אינו** מעניק עריכת הרשאות של מפתח קיים (זה `keys:update`). |
+| `keys:read` | `GET /keys` | רשימת מפתחות קיימים. סודות לעולם לא מוחזרים על ידי נקודת קצה זו. |
+| `keys:update` | `PATCH /keys/:id` | ערוך הרשאות של מפתח קיים. הרשאה **human/dashboard-only**; היא לא יכולה להיות מוקצה למפתח API (מפתח bearer עשוי ליצור מפתחות אך אף פעם לא לערוך אותם). |
+| `keys:disable` | `POST /keys/:id/disable` | שחזר מפתח. מפתחות מוגנים (`admin`, `dashboard-assistant`) לא יכולים להיות מבוטלים; סובב אותם דרך env var + restart. |
+| `keys:regenerate` | `POST /keys/:id/regenerate` | סובב סוד של מפתח. מפתחות מוגנים לא יכולים להיווצר מחדש דרך מסלול זה. |
+
+### משתמשי Dashboard
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `users:create` | `POST /users`, `GET /users/defaults` | הזמן משתמש dashboard חדש (משדרת email + one-time passcode (OTP) login) וקרא את ערכת ההרשאה default שהוגדרה ב-dashboard המשמשת seed את טופס ההזמנה. |
+| `users:read` | `GET /users`, `GET /users/:id` | רשימת משתמשים וטעינת רשומת משתמש יחידה. |
+| `users:update` | `PUT /users/:id` | ערוך הרשאות של משתמש. עדכונים משדרים email של שינוי הרשאות למשתמש המושפע ונכנסים לתוקף בבקשתם הבאה; לא נדרשת relоgin. |
+| `users:delete` | `DELETE /users/:id`, `POST /users/:id/enable` | בטל משתמש (שחזר את ה-sessions שלהם מיד) ו-re-enable משתמש שהיה מבוטל בעבר. |
+
+הרשאות אלה תומכות בעמוד **Users** של ה-dashboard, שם ההיקפים שניתנו של כל חבר מוצגים כ-chips:
+
+![עמוד Users: כרטיס לכל משתמש dashboard עם דוא"ל שלהם, הרשאות שניתנו, ובקרות עריכה/ביטול](/agenteye/images/users.png)
+
+### הגדרות תפעוליות
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `settings:read` | `GET /settings`, `GET /settings/schema`, `GET /settings/model-context-windows`, `GET /settings/model-context-windows/resolve` | צפה בהגדרות תפעוליות המנוהלות ב-dashboard ובמטה-דטה שלהן; רשימת overrides context-window per-model; וסגור את החלון האפקטיבי למודל. |
+| `settings:write` | `PUT /settings/:key`, `PUT /settings/model-context-windows`, `DELETE /settings/model-context-windows` | ערוך הגדרות תפעוליות והוסף, שנה, או הסר per-model context-window overrides. השינויים משפיעים על אירועים חדשים ללא restart של השרת. |
+
+![עמוד Settings: הגדרות תפעוליות המנוהלות ב-dashboard כגון sign-ins מורשים וחיי session/OTP, ניתנים לעריכה ללא restart](/agenteye/images/settings.png)
+
+### alerts ו-incidents
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `alerts:read` | `GET /alerts`, `GET /alerts/:id` | צפה בהגדרות alert שהוגדרו. |
+| `alerts:write` | `POST /alerts`, `PUT /alerts/:id`, `DELETE /alerts/:id`, `POST /alerts/:id/test` | יצירה, עריכה, מחיקה, ו-test-fire של הגדרות alert. |
+| `incidents:read` | `GET /alerts/incidents`, `GET /alerts/incidents/:iid`, `GET /alerts/incidents/:iid/comments`, `GET /alerts/incidents/:iid/subscribers` | צפה ב-incidents וב-triage trail שלהם. |
+| `incidents:write` | `POST /alerts/:id/incidents` | פתח incident ידנית נגד alert קיים. |
+| `incidents:ack` | `POST /alerts/incidents/:iid/ack`, `POST /alerts/incidents/:iid/assign`, `POST /alerts/incidents/:iid/resolve`, `POST /alerts/incidents/:iid/comments`, `POST /alerts/incidents/:iid/subscribe`, `POST /alerts/incidents/:iid/unsubscribe` | Acknowledge, assign, resolve, וcomment על incidents. |
+
+### Audits
+
+| הרשאה | מסלולי HTTP | מה זה מאפשר |
+|---|---|---|
+| `audits:read` | `GET /audits`, `GET /audits/:id`, `GET /audits/:id/runs`, `GET /audits/findings`, `GET /audits/findings/:fid` | צפה בהגדרות audit, היסטוריית run, וממצאים. |
+| `audits:write` | `POST /audits`, `PUT /audits/:id`, `DELETE /audits/:id`, `POST /audits/:id/run`, `POST /audits/findings/:fid/status` | יצירה, עריכה, מחיקה, וריצת audits; triage findings (acknowledge / mute / dismiss / resolve / reopen / assign). |
+
+> **הערה:** כדי להעניק למפתח את משטח audit, הענק `audits:*` לו באופן מפורש. ראה [הערות upgrade וחוזרים לאחור](#upgrade-and-backward-compatibility-notes) לאופן כיצד grantees קיימים הומיגרו כאשר Audits הושלח.
+
+> נקודת קצה של recipient-picker `GET /alerts/recipients` (המפרטת את אימיילי החברים שעורך alert יכול להודיע) ניתנת להשגה על ידי בעל **או** `alerts:read` **או** `alerts:write`, כך שעורכי alert יכולים למלא את הpicker ללא הענקת `users:read`.
+
+> צופה dashboards צריך **גם** `dashboards:read` (כדי לטעון את התצוגות השמורות) וגם `evaluations:read` (מטריקות הבריאות מחושבות מנתוני הערכה). הענק `dashboards:write` כדי לאפשר למשתמש ליצור או לערוך dashboards, ו`dashboards:delete` כדי להסיר אותם.
+
+> `/health` ו`/auth/*` (בקשת OTP, OTP verify, בדיקת session, logout) הם unauthenticated בעיצוב; הם זרימת הlogin וprobe של liveness. `GET /access-granters` דורש מפתח תקף אך ללא הרשאה ספציפית, כך שכל משתמש מחובר יכול לראות אילו admins ליצור קשר איתם לגבי שינויי גישה.
+
+---
+
+## ערכות הרשאות
+
+ערכות הרשאות מאפשרות לך להחיל תפקיד בעל שם במקום לבחור ידנית tokens בודדים בכל פעם. במקום לבחור תריסר הרשאות אחת אחת עבור כל משתמש dashboard חדש או מפתח API, אתה בוחר קבוצה, וכל אחד שמוקצה לה נושא הענקה עקבית וניתנת לביקורת. עריכת קבוצה מותאמת מחדש את ההענקה החדשה לכל משתמש שכבר מוקצה לה, כך ששינוי תפקיד הוא עריכה אחת ולא סריקה דרך כל חבר.
+
+כל organization זורעת עם שלוש קבוצות built-in:
+
+| קבוצה | הרשאות | מיועדת עבור |
+|---|---|---|
+| `read-only` | `events:read`, `keys:read`, `users:read`, `evaluations:read`, `dashboards:read`, `queries:read`, `settings:read`, `alerts:read`, `audits:read`, `incidents:read` | גישת view-only בכל משטח תפעולי. |
+| `standard` | כל דבר ב-`read-only`, בתוספת `evaluations:trigger`, `queries:run`, `incidents:ack`, `agent:use` | read-only בתוספת פעולות ה-on-caller היומיומיות: הריצו שאילתות, re-evaluate sessions, acknowledge incidents, והשתמש ב-AI assistant. |
+| `admin` | כל הרשאה assignable | בקרה מלאה של ה-org. |
+
+שלוש הקבוצות built-in הן **immutable**; השמות שלהם תמיד משמעות את אותו דבר, כך `read-only`, `standard`, ו`admin` בטוחים להפניה בpolicy וב-onboarding. אופרטור יכול ליצור **custom sets** נוספים כדי למודל תפקידים ספציפיים לארגון שלך (לדוגמה, תפקיד dashboard author או תפקיד collector-only).
+
+ערכות מוצגות ב-dashboard ומנוהלות על ה-API ב-`GET /permission-sets` (רשימה, gated על ידי `users:read`) ו`POST /permission-sets` / `PUT /permission-sets/:name` / `DELETE /permission-sets/:name` (יצירה, עריכה, מחיקה של קבוצה מותאמת, gated על ידי `settings:write`). מחיקה או עריכה של קבוצה built-in נדחית.
+
+חברות בקבוצה היא מה שתומך שתי תכונות אחרות:
+
+- **`DEFAULT_USER_PERMISSIONS`** (ההענקה preselected כשadmin פותח **+ new user**) מוגדרת כברירת מחדל לקבוצה `standard`.
+- **הדגל `--set`** ב-`agenteye-orgctl` (ניהול חברים של operator) מתחיל חבר מקבוצה בעל שם, ש-fine-tune אחר כך עם `--add` / `--remove`.
+
+> **הערה:** כאשר קבוצה כוללת הרשאה שאינה key-assignable (לדוגמה קבוצה מותאמת הנושאת `keys:update`), זריעה של מפתח מקבוצה זו מפילה את ה-tokens שאינם assignable; השרת אחרת היה דוחה את המפתח ב-HTTP 422. משתמשי Dashboard אינם כפופים להגבלה זו.
+
+---
+
+## מפתח Admin Bootstrap
+
+מפתח ה-admin הוא credential הroot היחיד שמאפשר לאופרטור להעלות גישה מלא: עם זה אתה יכול ליצור כל מפתח בהיקף אחר, להזמין את משתמשי dashboard הראשונים, ולהגדיר את ההופעה לפני שמפתח אחר קיים. זהו המפתח היחיד שאתה לא יוצר דרך מפתחות API; הוא מסופק מהסביבה כך השרת ניתן להשגה ב-first boot.
+
+הגדר את משתנה הסביבה `ADMIN_KEY` על השרת. בכל startup השרת עושה upsert של ערך זה כמפתח admin עם כל ההרשאות.
+
+כדי לסובב: שנה את `ADMIN_KEY` לסוד חדש והפעל מחדש את השרת.
+
+---
+
+## Organization scoping
+
+**Organizations עצמם יוצרים ומנוהלים out-of-band על ידי אופרטור, לא דרך keys API זה.** Org וחיי member (create / rename / delete / purge org; add / update / remove member) נעשים עם ה-**`agenteye-orgctl`** CLI; אין HTTP API או כפתור dashboard עבורו. מה *כן* בלתי שונה: **per-org API keys עדיין ממולכים ב-dashboard (או דרך keys API זה)** על ידי חברים של org.
+
+בהפעלה multi-org, כל מפתח שחבר org יוצר (דרך keys API זה או ה-dashboard **Keys** page) שייך ל-**organization אחת** ויכול רק אי פעם לקרוא או לכתוב את הנתונים של org זה; ה-org stamped על המפתח בזמן יצירה ומאוכף בכל בקשה. שני המפתחות bootstrap הם היוצא מן הכלל היחיד: מפתח ה-`admin` (זרוע מ-`ADMIN_KEY`) ומפתח ה-`dashboard-assistant` (זרוע מ-`AGENT_API_KEY`) הם **instance-scoped** (הם לא נושאים org). ה-dashboard מטפל כעם עם מפתח `admin` כך הוא יכול proxy per-org requests בעבור חברים שחתומים. single-tenant deployments לא צריכים לחשוב על זה; כל המפתחות שייכים ל-`default` org built-in.
+
+---
+
+## יצירת מפתחות
+
+השתמש במפתח ה-admin (או כל מפתח עם הרשאה `keys:create`) כדי ליצור מפתחות בהיקף נוסף.
+
+### Collector key (ingest only)
+
+```bash
+curl -s -X POST http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "prod-collector",
+    "key": "your-collector-secret",
+    "permissions": ["events:add"]
+  }'
+```
+
+### Dashboard key (read only)
+
+```bash
+curl -s -X POST http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "dashboard",
+    "key": "your-dashboard-secret",
+    "permissions": ["events:read", "keys:read"]
+  }'
+```
+
+כשאתה יוצר מפתח דרך HTTP API, אתה מספק את ערך `key` בעצמך; בחר בסוד חזק ואחסן אותו בבטחה. (ה-dashboard עובד בדרך אחרת: הוא יוצר סוד חזק עבורך ומראה אותו פעם אחת ביצירה; ראה [Key Management in the Dashboard](#key-management-in-the-dashboard).) התגובה מאשרת שהמפתח נוצר:
+
+```json
+{
+  "id": "550e8400-e29b-41d4-a716-446655440000",
+  "name": "prod-collector",
+  "permissions": ["events:add"],
+  "created_at": "2026-04-01T12:00:00Z"
+}
+```
+
+---
+
+## רישום מפתחות
+
+```bash
+curl -s http://your-server/keys \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+סודות מפתחות לא מוחזרים בתגובות רישום, רק IDs, שמות, והרשאות.
+
+---
+
+## ביטול מפתח
+
+ביטול שחזור גישה מיד ללא מחיקת רשומת המפתח.
+
+```bash
+curl -s -X POST http://your-server/keys/<id>/disable \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+---
+
+## סיבוב מפתח
+
+יוצר סוד חדש למפתח קיים. הסוד הישן מבוטל מיד.
+
+```bash
+curl -s -X POST http://your-server/keys/<id>/regenerate \
+  -H "Authorization: Bearer $ADMIN_KEY"
+```
+
+התגובה כוללת את הסוד בטקסט פשוט החדש, **מוצג רק פעם אחת**.
+
+---
+
+## ניהול מפתחות ב-Dashboard
+
+עמוד **Keys** ב-dashboard מספק UI עבור כל הפעולות לעיל. אתה צריך מפתח עם הרשאה `keys:read` כדי לצפות ברשימה, ו`keys:create` / `keys:update` / `keys:disable` / `keys:regenerate` עבור ה-create / edit / disable / regenerate פעולות בהתאמה. עריכה של הרשאות של מפתח (`keys:update`) היא נפרדת מיצירת אחד (`keys:create`), כך שאתה יכול להעניק לאופרטור את היכולת ליצור מפתחות ללא היכולת לשנות היקף של קיימים, או להיפך. מפתח ה-admin מכסה את כל אלה.
+
+כאשר אתה יוצר מפתח מה-dashboard אתה לא מספק את הסוד; ה-dashboard יוצר סוד חזק בשבילך ומציג אותו **פעם אחת** ביצירה. העתק אותו מיד ואחסן אותו בבטחה; הוא לעולם לא מוצג שוב, בדיוק כמו עם regenerate. אתה עדיין יכול לבחור את הרשאות המפתח ישירות, או לזרוע אותם מערכת הרשאות (ראה למטה).
+
+![עמוד API Keys: כרטיס לכל מפתח המציג את שמו, הרשאות שניתנו, וזמן יצירה, עם regenerate ו-disable פעולות; מפתחות מוגנים כמו `admin` מסומנים](/agenteye/images/api-keys.png)
+
+---
+
+## פריסת מפתחות מומלצת
+
+| מפתח | הרשאות | בשימוש על ידי |
+|---|---|---|
+| `admin` (bootstrap דרך env var `ADMIN_KEY`) | הכל | Ops/setup, ו-dashboard (אימות עם `ADMIN_KEY`, proxy בקשות משתמש עם בדיקות הרשאה) |
+| מפתח קולקטור per-host | `events:add` | קולקטור על כל מכונת אג'נט |
+| `dashboard-assistant` (bootstrap דרך env var `AGENT_API_KEY`) | `events:read`, `evaluations:read`, `dashboards:read`, `dashboards:write`, `queries:read`, `queries:write`, `queries:run` | AI assistant, זרוע באופן אוטומטי, **מוגן**; לא יכול להיות edited דרך ה-API |
+| מפתח telemetry של assistant (אופציונלי) | `events:add` | self-instrumentation של AI assistant, אם מופעל |
+
+> **הערה:** מפתח ה-assistant **זורע באופן אוטומטי** על ידי השרת מ-env var `AGENT_API_KEY` (אותו סוד שה-agent מציג כ-`AGENTEYE_API_KEY`); אין שלב key-minting ידני ואין מפתח admin מעורב. הרשאות שלו קבועות בקוד המקור כך ההיקף לא יכול להיות מורחב על ידי misconfiguration: קריאה על פני events / evaluations / dashboards, בתוספת dashboards-write ו-queries-read / write / run עבור זרימת authoring של Query AI Ask Write. כל ה-SQL עדיין עובר אותו role read-only בדיוק וguarded SQL path כמו query שנכתב על ידי משתמש, כך זה מרחיב את המשטח *authoring*, לא את משטח הנתונים; פעולות destructive (`queries:delete`, `dashboards:delete`) בכוונון להישאר off מפתח ה-assistant. כמו מפתח `admin`, הוא **מוגן**: הוא לא יכול להיות מבוטל או regenerated דרך keys API, רק סובב על ידי שינוי `AGENT_API_KEY` וrestart. משתמשי Dashboard בנוסף צריך את הרשאה `agent:use` כדי לראות ולהשתמש ב-assistant. אם אתה מפעיל self-instrumentation, תן ל-assistant מפתח נפרד `events:add`-only.
+
+---
+
+## הערות upgrade וחוזר לאחור תאימות
+
+אתה צריך אלה רק אם אתה משדרג instance קיים; פריסות חדשות יכולות לדלג עליהם.
+
+> כאשר Audits הושלח, grantees קיימים הורחבו לאורך אותן צורות תפקיד כמו alerts: כל משתמש וערכת הרשאות שמחזיק `alerts:read` הקבל `audits:read`, וכל בעל `alerts:write` הקבל `audits:write`. API keys קיימים **לא** הורחבו. הענק `audits:*` למפתח באופן מפורש אם הוא צריך את משטח audit.
+
+> Stored grants של ה-legacy token `alerts:ack` מנותחים כ-`incidents:ack` כך on-callers שומרים גישה ללא rekeying. ה-token כבר לא assignable מ-user editor של ה-dashboard; המטריצה מציעה `incidents:ack` במקום.
+
+---
+
+## צעדים הבאים
+
+- [Python SDK](/he/agenteye/python-sdk): כיצד קוד ה-agent שלך מטפל בהנחה כאשר שולח אירועים.
+- [Security](/he/agenteye/security): כיצד sign-in, access control, ו-per-organization data isolation עובדים.

package/.next/standalone/docs-old/he/agenteye/assistant.mdx

@@ -0,0 +1,63 @@
+---
+title: "עוזר AI"
+description: "שאל את נתוני הסוכן שלך שאלה באנגלית פשוטה וקבל תשובה המקושרת ישירות להוכחה."
+---
+
+
+שאל את נתוני הסוכן שלך שאלה באנגלית פשוטה וקבל תשובה המקושרת ישירות להוכחה. אין SQL לכתוב, אין לוחות מחוונים לדפדף דרכם — עוזר **Failproof AI Observability** הוא הדרך המהירה ביותר לכל אחד בצוות שלך לקבל תשובות על הסוכנים שלך.
+
+![עוזר Failproof AI Observability משיב לשאלה באנגלית פשוטה בתוך לוח המחוונים, המציג טבלת Agent Activity חיה, פירוט שימוש בדגם לכל סוכן, ותובנות כתובות, עם השאילתות שהוא הריץ המוצגות בשורה](/agenteye/images/assistant.png)
+*שאל באנגלית פשוטה וקבל תשובה שנבנתה מנתונים משלך. כאן הוא מפרק אילו סוכנים עסוקים ביותר ואילו דגמים הם משתמשים בהם, ומציג את השאילתות שהוא הריץ כדי שתוכל לאמת כל מספר.*
+
+אין מה ללמוד. פתח את הצ'אט, הקלד מה שאתה רוצה לדעת, וקבע את הקישורים שהוא מחזיר:
+
+```
+You:  which sessions errored today?
+AI:   5 sessions errored today, newest first. Each one is linked:
+      • checkout-agent   14:02   tool timeout
+      • billing-agent    11:47   unhandled error
+      • ...and 3 more
+
+You:  summarize this session          (asked while viewing a run)
+AI:   This run took 12 steps across 3 tools and failed near the end when a
+      payment tool returned an error. It scored low on your "resolved" eval.
+      Links: the session, the failing event, and that evaluation.
+```
+
+## פשוט שאל, וקפוץ ישר להוכחה
+
+אתה מפסיק לנחש ואתה מפסיק לכתוב שאילתות. שאל "איך איכות מתפתחת בייצור השבוע הזה?", "אילו הפעלות נכשלו היום?", או "סכם הפעלה זו," וקבל תשובה ישירה תוך שניות במקום לבנות שאילתה ולקרוא אותה בעצמך.
+
+כל תשובה מגיעה עם הקבלות שלה. העוזר מקשר את ההפעלות המדויקות, השאילתות השמורות, ולוחות המחוונים שהוא השתמש בהם כדי להגיע לתשובה, כדי שתוכל ללחוץ וליצור קישור ולאשר בזה לקחת את דברו על זה. הוא גם **page-aware**: שאל על "הפעלה זו" בזמן שאתה צופה בהפעלה אחת והוא כבר יודע איזו הפעלה אתה מתכוון. פתח מחדש כל שיחה מוקדמת יותר מאוחר מת דורג ההיסטוריה והמשך מהמקום שבו עזבת.
+
+## הפוך תשובה טובה לשאילתה שמורה או לוח מחוונים
+
+כאשר תשובה שווה את ההנצחה, בקש מהעוזר לשמור אותה. הוא משרטט את SQL לשאילתה שמורה, או מרכיב לוח מחוונים מאותן שאילתות, ואז מציג לך כרטיס **Approve / Reject**. שום דבר לא נכתב עד שתלחץ על Approve, כך שתקבל את המהירות של "פשוט שאל" כשהמילה האחרונה היא תמיד שלך.
+
+בעמוד **Queries** הוא הולך צעד קדימה הופך ללוחור SQL: תאר את השאילתה שאתה רוצה ("הצג שיעור שגיאה לפי סוכן במשך 7 הימים האחרונים") והוא זורם SQL ישר לעורך, ופוצה תצוגת diff כדי שתוכל **Accept** או **Reject** את השינוי לפני שהוא נוחת.
+
+![עמוד Observability Queries ועורך SQL שלו](/agenteye/images/query-lab.png)
+*עמוד Queries: עורך זה הוא המקום שבו העוזר זורם רק לקריאה שאילתה בדעת לך לקבל או לדחות.*
+
+לשם SQL על ידי שאילה כאן משתמש בהרשאה `queries:run`, אותה שלידה כפתור **Run** של העורך. צ'אט בכל מקום אחר זקוק `agent:use`.
+
+## בטוח להעביר לכל הצוות
+
+אתה יכול לפתוח את העוזר לכל אחד בלי לדאוג למה זה עשוי לגעת:
+
+- **הוא קורא רק מה שאתה כבר יכול לראות.** תשובות מתוחמות להרשאות הקריאה שלך, כך שהוא לעולם לא מרחיב את פני השטח של הנתונים שלך.
+- **כל כתיבה מחכה לך.** שאילתות שמורות ולוחות מחוונים נוצרים רק לאחר לחיצת Approve מפורשת, ואין הגדרה שהופכת את השער הזה.
+- **זה לעולם לא יכול למחוק שום דבר.** אין כלי מחיקה חשוף ללעוזר אין הרשאת מחיקה. מחיקות נשארות בידיך, בלוח המחוונים.
+- **זה נשאר בתוך הארגון שלך.** העוזר רואה רק את הארגון שאתה צופה כרגע.
+- **השאלות שלך נשארות שלך.** הנושאים והתשובות חיים בנתוני Observability שלך; רק ניתוחי המוצר מתעדים מטא -דטה שימוש, לעולם לא טקסט הנושא שלך.
+
+## איפה למצוא אותו
+
+העוזר רוכב על הקצה הימני של כל עמוד תחת הארגון שלך (`/<org-slug>/...`). לחץ על הרל, או לחץ על `⌘J` / `Ctrl+J`, כדי להרחיב אותו לפנל צ'אט מלא, וגרור את קצהו כדי לשנות את גודל; הרוחב שלך זכור על פני טעינות חוזרות. אתה זקוק להרשאת **`agent:use`** כדי להשתמש בו, אחרת הרל מכוסה. אם זה עדיין לא הופעל לפריסה שלך (זה צריך חיבור LLM), תראה רל מושתק במקום צ'אט עובד.
+
+## קשור
+
+- [CLI and agents](/he/agenteye/cli-and-agents)
+- [Queries](/he/agenteye/queries)
+- [Dashboards](/he/agenteye/dashboards)
+- [Evaluation suite](/he/agenteye/evaluation-suite)