diff --git a/CHANGELOG.md b/CHANGELOG.md index 9dc35d577..1599c138a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,11 @@ - `fp-cloud-cli`'s Click shim survives typer 0.27.2, which moved `Abort` out of its vendored Click. `_click_compat` wrapped all six vendored imports in one `try: … except ImportError: from click import …`, so that single missing name rebound **every** symbol to pip Click — the exact silent failure the module exists to prevent. Typer catches only its own Click's exceptions, so every typed error escaped uncaught: `fp alerts show ghost` exited 1 with an empty stderr instead of 6 with a message, and the same for exits 2, 3, 4 and 5. 105 tests went red on the dependabot bump that first installed 0.27.2. The Click is now chosen once — on whether `typer._click` exists at all — and each symbol imported from that choice, so a name that goes missing raises at import (a CLI that will not start) rather than silently downgrading every error to exit 1. `Abort` alone is resolved from `typer.Abort`, which tracks the move by construction: pip Click's before typer 0.26, the vendored class through 0.27.1, `typer.exceptions.Abort` from 0.27.2 (#771) +### Docs + +- The 1.0.2 documentation overhaul is reverted: `docs/` and `README.md` go back byte-for-byte to the commit #756 merged onto, along with the 14 generated locales and 14 translated READMEs #759 regenerated from those English sources. The release half of #756 stays — `package.json` and the Cargo workspace are untouched, since they have moved on to 1.0.4-beta.0 and the release tag the CLI builds its daemon download URL from is that npm version. Under `## 1.0.2` the heading and its release narrative stay, because 1.0.2 did ship; the `### Docs` entries underneath described the overhaul and go with it. Leaving the locales in place was the alternative considered and rejected: the nightly translate job is content-hash cached, so pages whose pre-overhaul English hashes it had already seen would have been skipped rather than repaired, stranding every non-English reader on a translation of text that no longer exists (#773) +- The landing page no longer opens with the harness paragraph claiming that "the same events, the same policies, and the same session history apply to every one" of the twelve. Removed from `docs/index.mdx` and all 14 locales (#773) + ### Dependencies - `fp-cloud-cli`: typer 0.27.1 → 0.27.2, click 8.4.2 → 8.5.0, posthog 7.42.0 → 7.44.2 (#771) @@ -54,16 +59,6 @@ pinned by the digest of its artifact and by the commit it was built from, and a pack that cannot be loaded DENIES within the scope it declared rather than disappearing quietly. -### Docs - -- The documentation is rewritten against the shipped 1.0.2 CLI. An audit of all 68 English pages plus the README found 219 factual errors, and the whole of `start/` documented a setup path that no longer exists: bare `failproofai config` — the verb that installs the daemon and wires every supported agent CLI — appeared on no page, and neither did `failproofai policies add FailproofAI/policies`, so a reader who followed the quickstart end to end finished with hook entries, no daemon, and one enforcing policy. The retired `pack`/`policy` spellings, `pack add core`, `--bundled` and `config --connect --token ` are gone; the local no-account path (the dashboard on `localhost:8020`, local findings from `failproofai audit`, and separately documented telemetry controls) is documented for the first time; and `start/integrations.mdx`, which five pages linked to and nothing in the navigation reached, is wired in (#756) -- Observe mode is documented as what it is: the policy is EVALUATED for real, under the same timeout and error handling as an enforcing one, and its verdict recorded — only the enforcement is withheld. Both layers that set it are named, `failproofai publish --effect observe` for a pack and `fp fleet deploy --add :observe` for a Cloud deployment, and every page showing `--add` now says that a bare one ENFORCES immediately, which is how a shadow rollout turns into a production incident. `policies/deploy.mdx` had described the workflow entirely as dashboard clicks and named no `fp` command at all; the CLI lane — `fp fleet list/show/deploy/diff/history/rollback`, `fp guardrails summary|timeline`, and `fp policies test`, which decides a policy locally with no server and no auth — is now covered (#756) -- Enforcement is no longer described as uniform across the twelve harnesses. `docs/index.mdx` claimed "the same events, the same policies, and the same session history apply to every one" — the exact claim `src/hooks/enforcement-capability.ts` exists to stop drifting. A `PreToolUse` deny is verified to stop the tool on all twelve; a `Stop` deny is verified on eight, is `observe` on Pi, and is unverified on OpenCode, Hermes and Goose. Goose has no `Stop` event and we install none on Hermes, so the five `require-*-before-stop` builtins never fire on either. A pair with no row in that file now reads as unverified rather than as blocking (#756) -- The install no longer claims that policies come with it. "39 built-in policies activate immediately" and "eleven are on when you accept the defaults" were both false: `configure-wizard.ts` enables nothing, so `enabledPolicies` is empty and `builtin-policies.ts` registers only what carries `alwaysOn` — exactly one policy, `block-failproofai-commands`. The eleven `defaultEnabled` flags are catalog metadata that decide nothing until a pack is installed (#756) -- The Policy Hub at befailproof.ai/policy-hub is documented, including that `failproofai publish` does not set the `failproofai-policies` topic the hub indexes on — so publishing is publish-then-tag-by-hand until it does (#756) -- Two claims copied out of the CLI's own `--help` are corrected, because the help is wrong. Scope support is not "Codex, Copilot, Cursor, OpenCode and Pi take user or project only": `types.ts` makes Hermes and OpenClaw **user-only** and gives `local` to Claude alone. And `backfill --help` names `~/.failproofai/config.toml`, a layout-2 file no current build writes; the file is `config.json` (#756) -- Six fabricated commands and flags were caught by an adversarial verification pass before they shipped, among them `fp fleet rename --name` (the command takes two positionals and declares no options), a `tool` filter on the local dashboard's activity view (`HookActivityFilters` has six keys and tool is not one), and `failproofai config --token --machine-label ` as a setup one-liner — which sets nothing up, since any invocation carrying `--machine-label` without `--connect` routes straight to the rename path and exits 1 on a machine that is not yet connected (#756) - ### Fixes - The mirror of that, on the success path: a shared artifact that imports FINE but registers less than one of its packs selected. Registration is recorded per pack id, and every hook from a collapsed load carries only the id the collapse kept — so a policy declared by the non-winning record's manifest and absent from the artifact left that pack in neither the failure map nor the registered map, and `missingGuards` skips a pack in neither. Nothing registered the policy and nothing denied on its behalf: the machine reported itself enforcing a scope that was running nothing. Registrations are propagated to every pack id behind the artifact now, so the pack that selected the missing policy is measured against what actually loaded (#738) diff --git a/README.md b/README.md index d2be7306a..636d2666b 100644 --- a/README.md +++ b/README.md @@ -14,11 +14,11 @@ **Translations:** [简体中文](./docs/i18n/README.zh.md) · [日本語](./docs/i18n/README.ja.md) · [한국어](./docs/i18n/README.ko.md) · [Español](./docs/i18n/README.es.md) · [Português](./docs/i18n/README.pt-br.md) · [Deutsch](./docs/i18n/README.de.md) · [Français](./docs/i18n/README.fr.md) · [Русский](./docs/i18n/README.ru.md) · [हिन्दी](./docs/i18n/README.hi.md) · [Türkçe](./docs/i18n/README.tr.md) · [Tiếng Việt](./docs/i18n/README.vi.md) · [Italiano](./docs/i18n/README.it.md) · [العربية](./docs/i18n/README.ar.md) · [עברית](./docs/i18n/README.he.md) -**See what your agents do. Stop known failures before they repeat.** -Failproof AI works wherever your agents run: coding tools like Claude Code and -Codex, chat gateways like Hermes, self-hosted assistants like OpenClaw, and agents -you instrument yourself. It records each run and can block dangerous tool calls -before they execute. +**Observability and enforcement for every harness your agents run in.** +Wherever your agents run, we see it — and we can say no. Failproof hooks 12 agent +harnesses — coding CLIs like Claude Code and Codex, chat gateways like Hermes, +self-hosted assistants like OpenClaw — capturing every run and blocking dangerous +tool calls before they execute. 39 built-in policies. Zero latency. Runs locally. @@ -30,9 +30,9 @@ before they execute. ## Supported harnesses -Twelve harnesses in two classes are supported: ten coding CLIs, plus two -gateways: Hermes, OpenClaw. The policy API and session history are shared; which -events can block varies by harness. +Twelve harnesses in two classes — ten coding CLIs, and two chat and assistant +gateways (Hermes, OpenClaw). Same events, same policies, same session history, +whichever one your agent runs in. Agents that run in none of them report through the [Python SDK](https://docs.befailproof.ai/reference/custom-agents), which gives you tracing, sessions and audits. Enforcement there needs a hook in @@ -134,31 +134,13 @@ your own runtime — [talk to us](mailto:support@befailproof.ai) and we'll map i ## Install -Give a compatible agent the Failproof AI skill if you want it to guide setup, -inspect the machine, and route policy, audit, session, and Cloud work correctly: - -```sh -npx skills add FailproofAI/skills -``` - -This installs the umbrella skill and its specialist siblings. To install only the -umbrella, add `--skill failproofai`. Skills supply operating instructions; install -and configure the product itself with: - ```sh npm install -g failproofai -failproofai config -failproofai policies add FailproofAI/policies -failproofai # dashboard on localhost:8020 +failproofai policies --install # or just run `failproofai` and accept the first-run prompt +failproofai ``` -Setup connects supported agents and installs the background service. It chooses no -policy pack: before you add one, only `block-failproofai-commands` runs to stop an -agent disabling Failproof AI. - -Connect Cloud without prompts with `failproofai config --token `. On a -shared machine or in CI, set `FAILPROOFAI_CLOUD_TOKEN` and run `failproofai config` -so the key does not appear in command history. +39 built-in policies activate immediately. Dashboard at `localhost:8020`. Disable the first-run prompt with `FAILPROOFAI_NO_FIRST_RUN=1`. --- @@ -175,8 +157,8 @@ so the key does not appear in command history. | `block-rm-rf` | Recursive file deletion | | `block-force-push` / `block-push-master` | `git push --force`, direct pushes to `main` | -These policies protect files, credentials, infrastructure, databases, and agent -workflows. Exact enforcement support varies by harness and event. +The first five apply to any agent that can call a tool. The last three are the +developer favourites — coding CLIs are the harness class we cover deepest. → [All 39 built-in policies](https://docs.befailproof.ai/policies/builtin) @@ -213,33 +195,6 @@ Three decisions available to every policy: --- -## Policy packs - -A policy pack is a versioned set of policies published from a public GitHub -repository. Inspect one before installing it: - -```sh -failproofai policies show FailproofAI/policies -failproofai policies add FailproofAI/policies -``` - -Anything with a slash is a pack source; anything without one is a policy name. -You can install selected categories or policies, and pin a release when needed. - -```sh -failproofai policies add FailproofAI/policies --category git,database -failproofai policies add owner/repo@a1b2c3d4e5f6 -``` - -Browse published packs in the [Policy Hub](https://befailproof.ai/policy-hub/), or -run `failproofai publish --init` to start your own. Observe mode lets a pack record -what it would have done without blocking: `failproofai publish --effect observe`. - -→ [Policy packs](https://docs.befailproof.ai/policies/packs) · -[Publish a pack](https://docs.befailproof.ai/policies/publish-a-pack) - ---- - ## Observability Enforcement is one half. The other half is seeing what the agent actually did. diff --git a/docs/admin/keys-and-permissions.mdx b/docs/admin/keys-and-permissions.mdx index b95df0130..82ca36dc2 100644 --- a/docs/admin/keys-and-permissions.mdx +++ b/docs/admin/keys-and-permissions.mdx @@ -1,54 +1,74 @@ --- title: "Keys and permissions" -description: "Create credentials for people, automation, and machines." +description: "Create scoped API keys for machines, automation, and operators." icon: "key-round" --- -Use a separate key for each person, machine, or automation job. Grant only the permissions it needs. +API keys belong to an organization and carry explicit permissions. Use separate keys for agent ingestion, policy delivery, evaluators, CI automation, and administrative scripts. ## Create and rotate a key -Use **Admin → Keys**, or the Cloud CLI: + + + 1. Go to **Administration → Keys**, select **new key**, and enter a workload name. + 2. Choose a permission set and adjust individual permissions only when the preset is insufficient. + 3. Create the key and copy its one-time secret immediately. + 4. Open the key later to update grants, disable it, or regenerate the secret. -```bash -fp keys list -fp keys create "audit automation" --add audits:read -fp keys disable "audit automation" -``` + The creation drawer is where you choose the narrowest grants required by the workload. -Store the secret when it is created; it is not shown again. Rotate by creating a replacement, updating the consumer, then disabling the old key. + ![The new API key drawer with permission presets and individual grants.](/images/dashboard/key-create.png) -## Machine keys + After creation, the Keys page shows the persistent metadata and management actions. The one-time secret is not shown again. -A machine key connects the local service to Cloud: + ![The API Keys page showing key permissions, creation time, and regenerate and disable actions.](/images/dashboard/api-keys.png) -```bash -export FAILPROOFAI_CLOUD_TOKEN="" -failproofai config -``` + Use this list to review grants regularly and disable keys that no longer map to an active workload. + + + ```bash + fp keys create production-agents \ + --add events:add \ + --add policies:pull + fp keys show production-agents + fp keys update production-agents --add events:read + fp keys regenerate production-agents --yes + fp keys disable production-agents + ``` -A connected machine may need two capabilities: + Redirect or capture create/regenerate output securely; the secret is returned once. + + -- `policies:pull` to receive Cloud-managed policies. -- `events:add` to send decisions and sessions. +The two permissions required by a connected Failproof AI machine are independent: -Status reports these separately because one may work while the other does not. +- `events:add` sends events and session data. +- `policies:pull` retrieves assigned policy deployments. -## Common permissions +Key secrets are shown when created or regenerated. Store them in a secret manager and rotate them without reusing an operator's interactive credentials. -| Permission | Allows | +## Permission catalog + +| Area | Permissions | | --- | --- | -| `events:add` | Send events | -| `events:read` | Read events and errors | -| `evaluations:read` | Read sessions and evaluations | -| `audits:read` / `audits:write` | Review or manage audits | -| `policies:read` / `policies:write` | Review or deploy policies | -| `policies:pull` | Pull machine policy assignments | -| `keys:create` / `keys:disable` | Create or disable keys | -| `orgs:admin` | Instance-level organization administration; not assignable to an organization key | +| Events | `events:add`, `events:read` | +| Keys | `keys:create`, `keys:read`, `keys:disable`, `keys:regenerate`; `keys:update` is human-session only | +| Users | `users:create`, `users:read`, `users:update`, `users:delete` | +| Evaluations | `evaluations:read`, `evaluations:trigger` | +| Dashboards | `dashboards:read`, `dashboards:write`, `dashboards:delete` | +| Queries | `queries:read`, `queries:write`, `queries:delete`, `queries:run` | +| Assistant | `agent:use` | +| Settings | `settings:read`, `settings:write` | +| Alerts | `alerts:read`, `alerts:write` | +| Issues | `issues:read`, `issues:create`, `issues:close` | +| Audits | `audits:read`, `audits:write` | +| Policies | `policies:read`, `policies:write`, `policies:pull` | +| Usage | `usage:read` | + +`orgs:admin` is reserved for the instance operator and cannot be granted to an organization key or ordinary member. Retired `incidents:*` and `alerts:ack` tokens are accepted for compatibility and normalize to current `issues:*` permissions. -Some administrative `fp fleet` and `fp guardrails` commands require a signed-in user session rather than an API key. Their help text states this before making a request. +Builtin permission sets are `read-only`, `standard`, and `admin`. `standard` adds evaluation triggering, query execution, issue response, and assistant use to read permissions. Key creation strips human-only grants even when a permission set contains them. - Never reuse ingest credentials such as `AGENTEYE_KEY` or `AGENTEYE_API_KEY` as an `FP_API_KEY`. They serve different systems and permissions. + Instance-scoped keys can select an organization with the `X-AgentEye-Org` header. Set it explicitly on multi-organization deployments; omission may select the default organization. diff --git a/docs/admin/overview.mdx b/docs/admin/overview.mdx index 04c476d70..83125f00e 100644 --- a/docs/admin/overview.mdx +++ b/docs/admin/overview.mdx @@ -1,30 +1,22 @@ --- title: "Administration" -description: "Operate Cloud access, membership, settings, and consumption without mixing them into the reliability workflow." +description: "Operate access, usage, organizations, and security without mixing them into the reliability workflow." icon: "settings-2" --- -Administration is the Cloud half of Failproof AI. Organizations, members, API keys, org settings, and metered consumption all need a Cloud connection. - - - Failproof AI also runs with no account at all. A local machine enforces policy, keeps its session history on disk, serves the [local dashboard](/reference/local-dashboard) on `localhost:8020`, and runs `failproofai audit` without sending anything anywhere. See [machine configuration](/reference/events-and-configuration#machine-configuration) for the local `collector` keys. Skip the rest of this section if you are not using Cloud. - - -## Where the controls live +Administration contains the controls needed to run Failproof AI across a team. Most readers can stay in Sessions, Audits, and Policies; administrators use this section to manage access and operating boundaries. - The Cloud sidebar's **admin** group holds **policy editor**, **enforcement**, **usage**, **keys**, **users**, and **settings**. + Use the Cloud sidebar's **Admin** section for **policy editor**, **enforcement**, **usage**, **keys**, **users**, and **settings**. A locked item shows that your account is missing its read permission. - ![The admin group of the Cloud sidebar with policy editor, enforcement, usage, keys, users, and settings.](/images/dashboard/admin-navigation.png) + ![The Admin section of the Cloud sidebar with policy editor, enforcement, usage, keys, users, and settings.](/images/dashboard/admin-navigation.png) - Install the Cloud CLI as an isolated tool, then sign in: - ```bash - uv tool install fp-cloud-cli - fp login fp whoami + fp orgs current + fp orgs perms fp usage ``` @@ -32,43 +24,17 @@ Administration is the Cloud half of Failproof AI. Organizations, members, API ke -## Signed-in human, or API key - -`fp` runs in one of two authentication modes, and the split decides which commands work. A command an API key cannot perform refuses before it opens a connection and names the reason, rather than letting a 401 or a 403 stand in for it. - -| Command | API key | Permission | -| --- | --- | --- | -| `fp whoami` | Yes | none | -| `fp usage` | Yes | `usage:read` | -| `fp keys list` / `show` | Yes | `keys:read` | -| `fp keys create` | Yes | `keys:create` | -| `fp keys disable` | Yes | `keys:disable` | -| `fp keys regenerate` | Yes | `keys:regenerate` | -| `fp keys update` | No | `keys:update`, which no key can hold | -| `fp users list` / `show` | Yes | `users:read` | -| `fp users create` | Yes | `users:create` | -| `fp users update` | Yes | `users:update` | -| `fp users disable` / `enable` | Yes | `users:delete` | -| `fp settings list` / `schema` | Yes | `settings:read` | -| `fp settings set` | Yes | `settings:write` | -| `fp orgs list` / `switch` / `current` / `perms` | No | signed-in session only | - -`fp usage` is the command to give a reporting script: it runs unattended under a key and needs only `usage:read`. - + + Inspect billing windows and organization consumption. + - Mint the machine credential, and give every workload only the grants it needs. + Give machines and automation only the permissions they require. - Manage membership, and keep each organization's data and actions scoped. + Manage membership, defaults, and organization boundaries. - Set sign-in and alerting values, and decide what agent data leaves a machine. - - - Read what the organization metered during its current 30-day window. - - - See which machines are enrolled, how they are identified, and what they enforce. + Configure operational settings, data handling, and deployment security. diff --git a/docs/admin/settings-and-security.mdx b/docs/admin/settings-and-security.mdx index 672ae7d37..5809a4c9f 100644 --- a/docs/admin/settings-and-security.mdx +++ b/docs/admin/settings-and-security.mdx @@ -1,37 +1,68 @@ --- title: "Settings and security" -description: "Control organization defaults, data handling, and machine credentials." -icon: "shield" +description: "Configure operational settings and make deliberate choices about agent data." +icon: "lock-keyhole" --- -Organization settings affect everyone in that Cloud organization. Change them from **Admin → settings** or with `fp settings`. +Use Settings for deployment-specific operational values and model context-window overrides. Inspect the settings schema before changing a value through the API or CLI. -```bash -fp settings list -fp settings set -``` +## Change an organization setting -## Data handling + + + 1. Go to **Administration → Settings**, find the setting group, and read its description and current source. + 2. Change the value and save it. + 3. For model context windows, add or update the model override and confirm the effective limit. + 4. Recheck sessions and metrics that depend on the changed value. -A connected machine sends policy decisions and full session transcripts by default. To send decisions only, set `collector.sessions` to `false` in the machine's `~/.failproofai/config.json` after connecting. The current `--no-transcripts` setup flag does not apply that setting. + ![The Settings page showing organization authentication and operational settings.](/images/dashboard/settings.png) + + + ```bash + fp settings list + fp settings schema + fp settings set --value + fp settings set alerts.email_default_recipients \ + --json-value '["oncall@example.com"]' + ``` -Credentials are scrubbed on the machine before upload, but redaction is a safety floor, not a substitute for access control. + Run `fp settings set --help` for the value type and confirmation flags used by the installed CLI. + + -Local-only use needs no account. Session history and audits stay on the machine, except scheduled local audits send machine identity and a limited digest after you opt in. Anonymous CLI telemetry can be disabled with `FAILPROOFAI_TELEMETRY_DISABLED=1`. +## Data handling choices -## Credentials +Connecting the Failproof AI CLI sends transcripts by default because traces and audits depend on their content. Use `--no-transcripts` when prompts, file contents, or terminal input must remain local; hook activity and policy decisions can still be reported. -Machine tokens are stored under `~/.failproofai/` with owner-only permissions. They are not written into the service definition. +Local ingest credentials are stored separately from non-secret daemon settings and written with restrictive permissions. API keys should still be managed as production secrets. -Use separate keys for people, automation, and machines. Give each only the permissions it needs, rotate it when ownership changes, and revoke it when the machine or workflow is retired. +## Organization setting reference -## Checklist +All dashboard-editable settings are organization-scoped. Deployment-wide behavior remains server environment configuration. -- Require the narrowest useful permissions. -- Set `collector.sessions` to `false` where full content is unnecessary. -- Review who can deploy enforcing policies. -- Test policies in observe mode before enforcement. -- Keep machine labels clear and machine IDs stable. -- Run `failproofai config --status` after changing connection settings. +| Key | Default | Purpose | +| --- | --- | --- | +| `allowed_sign_ins` | `[]` | Restrict existing members to exact emails or `*@domain`; an empty list means no additional restriction. | +| `session_ttl_secs` | `86400` | Dashboard session lifetime; accepted range is 60 seconds to 30 days. | +| `otp_ttl_secs` | `600` | OTP and magic-link lifetime; accepted range is 60–1800 seconds. | +| `alerts.email_default_recipients` | `[]` | Default recipients when an alert email channel does not override them. | +| `alerts.slack_default_webhook` | empty | Default Slack incoming-webhook URL. | +| `alerts.webhook_default_url` | empty | Default generic JSON webhook URL. | +| `alerts.webhook_signing_secret` | empty | HMAC-SHA256 key used for the `X-AgentEye-Signature` header; reads are masked. | +| `alerts.enabled_channels` | email, Slack, webhook | Organization-wide channel kinds that alert rules may dispatch. | +| `default_user_permissions` | `standard` | Named permission set preselected for new invitations. | -See [keys and permissions](/admin/keys-and-permissions) for the permission catalog. +`allowed_sign_ins` is a filter, not a grant: a person must already be an organization member. Use an empty list to allow every member; the bare value `*` is rejected. Alert URLs must use HTTPS except for loopback development addresses. + +## Security checklist + +- Use HTTPS for Cloud connections. +- Scope keys to the smallest permission set. +- Separate production and non-production environments. +- Review transcript and redaction settings before rollout. +- Audit user, key, and organization changes. +- Test backup, retention, and incident response requirements for your deployment. + + + Turning transcript capture off changes what audits and investigations can prove. Record the decision and its expected limitations. + diff --git a/docs/admin/usage.mdx b/docs/admin/usage.mdx index d2a524fca..056179495 100644 --- a/docs/admin/usage.mdx +++ b/docs/admin/usage.mdx @@ -1,24 +1,21 @@ --- title: "Usage" -description: "Inspect organization consumption for the current 30-day metering window." +description: "Inspect organization consumption and the active billing window." icon: "chart-no-axes-combined" --- -Usage shows what the current organization has metered during its current 30-day window. The window is fixed and anchored per organization, and usage is read-only: it applies and displays no limits, quotas, or plan thresholds. Both surfaces say so — the CLI panel prints "read-only usage, no limits applied". +Usage shows consumption for the current organization and its billing windows. Use it to understand how production rollout, transcript volume, evaluations, and audit cadence affect your plan. ## Review usage - 1. Go to **admin → usage**. - 2. Confirm the organization and the metering window — the header shows the window's start and end, the day within it, and how much has elapsed. - 3. Read the hero block: events ingested, sessions, agents, and environments. - 4. Read the two pipelines: evaluations (with scores and metrics) and audits (with issues and alerts), each showing completed runs against started runs. - 5. Read the workspace and access blocks: saved queries, dashboards, alerts, unique issues, members, and API keys. + 1. Go to **Administration → Usage**. + 2. Confirm the organization and metering window. + 3. Review ingest, sessions, evaluations, metrics, audits, findings, alerts, users, and keys. + 4. Compare started and completed audit work when audit usage looks unexpected. - The figures are cached, not live. Use the refresh control in the top right after a change you expect to see. - - ![The usage page showing the metering window, events captured, the evaluation and audit pipelines, workspace resources, members, and API keys.](/images/dashboard/usage-overview.png) + ![The Usage page showing the metering window, captured events, evaluation and audit pipelines, workspace resources, members, and API keys.](/images/dashboard/usage-overview.png) ```bash @@ -26,52 +23,15 @@ Usage shows what the current organization has metered during its current 30-day fp --json usage fp --org reliability-team --json usage ``` - - `fp usage` needs `usage:read` and runs under an API key, which makes it the right command for a reporting cron. - - With `--json` it returns the dashboard response unchanged: `org_id`, `billing_anchor`, `window`, `usage`, `calculated_at`, and `stale_after`. `calculated_at` and `stale_after` are how you tell how old a figure is. - - `fp usage` takes no flags of its own — only the global `--json` and `--org`. It reports the current window and nothing before it, so keep your own history by running it on a schedule and storing the `--json` payload rather than expecting to query an earlier window later. - - ```bash - fp --json usage | jq '.usage.events_ingested' - ``` -### Metric keys - -Everything under `usage` in the JSON payload, so a script can name a field instead of parsing a panel. - -| Group | Keys | -| --- | --- | -| Telemetry | `events_ingested`, `sessions`, `agents`, `environments` | -| Evaluations | `evaluation_runs`, `evaluation_finishes`, `evaluations`, `metrics` | -| Audits | `audit_runs`, `audit_finishes`, `issues_created`, `alerts_created` | -| Workspace | `queries_created`, `dashboards_created` | -| Access | `users_active`, `users_created`, `keys_active`, `keys_created` | - -Each pipeline reports started and finished counts separately, so a gap between `audit_runs` and `audit_finishes` means work that began and did not complete — worth checking before you read anything into the issue counts beneath it. - ## Investigate a change -Ingest volume is decided per machine, not centrally. Start from the organization and window, then work through what changed on the machines reporting into it. - -| Cause | Where to check | What to change | -| --- | --- | --- | -| A machine is sending session transcripts | `collector.sessions` in that machine's `~/.failproofai/config.json` | Set it to `false` to send decisions only | -| Hook activity is being sent in full | `collector.hooks_verbosity` in the same file | `decisions` aggregates allows per minute; `off` stops hook events entirely | -| A new capture location was added | `failproofai harness list` | Remove it with `failproofai harness remove-path ` | -| History was re-sent | The machine's `failproofai backfill` runs | Re-sends deduplicate on a content hash and collapse into rows already there, so they do not double-count | -| A new integration started reporting | The `agents` and `environments` counts, and the sessions list | Scope the new machine's collector settings before rolling it out | - -Usage compares nothing against a plan. Do that outside the product. +1. Confirm the active organization and window. +2. Compare the increase with session volume by environment. +3. Check whether a new integration started sending transcripts. +4. Review evaluator and audit cadence changes. +5. Compare against the limits on the current pricing plan. - - - The per-machine data-handling settings behind these numbers. - - - The full `fp` surface, including installation and sign-in. - - +The CLI returns the same summary for scripts. diff --git a/docs/admin/users-and-organizations.mdx b/docs/admin/users-and-organizations.mdx index 5340f724f..2ff1dea77 100644 --- a/docs/admin/users-and-organizations.mdx +++ b/docs/admin/users-and-organizations.mdx @@ -4,13 +4,18 @@ description: "Control membership and keep each organization's data and actions s icon: "users" --- -Organizations isolate sessions, evaluations, audits, issues, alerts, queries, dashboards, users, and keys. Confirm the active organization before you change any administrative resource. +Organizations isolate sessions, evaluations, audits, issues, alerts, queries, dashboards, users, and keys. Confirm the active organization before changing administrative resources. -## Choose the organization +## Manage members and organizations - Use the organization switcher at the top of the Cloud sidebar. Everything below it — including every page in **admin** — then reads and writes that organization. + 1. Use the organization switcher at the top of the Cloud sidebar to change organizations. + 2. Go to **Administration → Users** to search members or filter by active state and role. + 3. Select **new user**, enter the email, choose a permission set, and adjust overrides if needed. + 4. Open a user later to update grants, disable sign-in, or enable the account again. + + ![The Users page showing member email addresses, permission sets, and edit and disable controls.](/images/dashboard/users.png) ```bash @@ -18,62 +23,22 @@ Organizations isolate sessions, evaluations, audits, issues, alerts, queries, da fp orgs switch reliability-team fp orgs current fp orgs perms - ``` - - `fp orgs switch` with no slug opens an arrow-key picker starting on your current organization; a non-interactive run falls back to a numbered prompt, and under `--json` a slug is required. The choice persists to `~/.failproofai/fpcli/cli-auth.json`, so later commands send it as the active tenant. Override it for one command with `--org ` or `FP_ORG`. - - - - - Every `fp orgs` command needs a signed-in human and refuses under an API key, because org membership belongs to a person and a key already acts for one organization. The `fp users` commands below work either way. - - -## Manage members - - - - 1. Go to **admin → users** and search members by email, or narrow the list with the `protected`, `admin`, `standard`, and `read-only` filter chips. - 2. Select **new user**, enter the email, choose a permission set, and adjust per-member overrides if needed. - 3. Open a member later to change grants, disable sign-in, or enable the account again. - ![The users page with the email search box, the filter chips, and a member card showing its grants grouped by resource.](/images/dashboard/users.png) - - The grant chips in this frame predate the `incidents:*` to `issues:*` rename; the [common permissions](/admin/keys-and-permissions#common-permissions) list is current. - - - ```bash - fp users list - fp users list --active-only fp users create engineer@example.com --permission-set standard fp users show engineer@example.com fp users update engineer@example.com --add audits:write fp users disable engineer@example.com fp users enable engineer@example.com ``` - - Members are addressed by email and resolved case-insensitively, so `fp users show Alice.Chen@Example.com` and `fp users create alice.chen@example.com` refer to the same person. -### Grants, and what each verb needs - -Member grants use the same arithmetic as keys: effective grants are `(set ∪ added) − removed`, and `--add` / `--remove` take compact `slug:action.action` tokens where dotted actions expand. See [keys and permissions](/admin/keys-and-permissions). - -| Verb | Permission | Notes | -| --- | --- | --- | -| `fp users list` / `show` | `users:read` | `--active-only` hides disabled members. | -| `fp users create` | `users:create` | `--permission-set` seeds the role; `--add` / `--remove` layer overrides. | -| `fp users update` | `users:update` | `--permission-set` **replaces** the member's per-member overrides; `--add` / `--remove` alone are incremental against their current grants. | -| `fp users disable` / `enable` | `users:delete` | Both, including enable — grant it deliberately. | - -Disabling refuses two cases outright, as a Forbidden error rather than a validation message: a **protected** member cannot be disabled, and you cannot disable your own account. Disabling an already-disabled member, or enabling an already-active one, is a calm no-op. The API uses a delete operation for disabling, but it removes neither the account nor its membership record. - -Two organization settings govern membership: `default_user_permissions` preselects the permission set for a new invitation, and `allowed_sign_ins` gates which addresses can receive a sign-in code at all. Manage them from the [settings page](/admin/settings-and-security). +Administrators can create, update, disable, and re-enable users, then assign the permission set appropriate for their role. The API uses a delete operation for disabling, but it does not remove the account or its membership record. Disabling a user blocks that identity from signing in to every organization, not only the organization currently selected. Re-enabling restores global sign-in and the member's permissions in this organization. - Give service accounts descriptive names tied to a workload and an owner. Do not share a key between organizations, or between a person and a machine. + Give service accounts descriptive names tied to a workload and owner. Avoid sharing keys between organizations or between people and machines. diff --git a/docs/ar/admin/keys-and-permissions.mdx b/docs/ar/admin/keys-and-permissions.mdx index 6c067bb02..1a402c6f6 100644 --- a/docs/ar/admin/keys-and-permissions.mdx +++ b/docs/ar/admin/keys-and-permissions.mdx @@ -1,54 +1,74 @@ --- title: "المفاتيح والأذونات" -description: "إنشاء بيانات اعتماد للأفراد والأتمتة والآلات." +description: "أنشئ مفاتيح API ذات نطاق محدد للآلات والأتمتة والمشغّلين." icon: "key-round" --- -استخدم مفتاحًا منفصلًا لكل شخص أو آلة أو مهمة أتمتة. امنح فقط الأذونات التي تحتاجها. +تنتمي مفاتيح API إلى منظمة وتحمل أذونات صريحة. استخدم مفاتيح منفصلة لاستيعاب الوكلاء، وتسليم السياسات، والمقيّمين، وأتمتة CI، والبرامج الإدارية. ## إنشاء وتدوير مفتاح -استخدم **Admin → Keys**، أو واجهة سطر الأوامر للسحابة: + + + 1. انتقل إلى **Administration → Keys**، اختر **new key**، وأدخل اسم حمل العمل. + 2. اختر مجموعة أذونات واضبط الأذونات الفردية فقط عندما تكون مجموعة الإعدادات المسبقة غير كافية. + 3. أنشئ المفتاح وانسخ سرّه لمرة واحدة فوراً. + 4. افتح المفتاح لاحقاً لتحديث المنح أو تعطيله أو إعادة توليد السرّ. -```bash -fp keys list -fp keys create "audit automation" --add audits:read -fp keys disable "audit automation" -``` + درج الإنشاء هو حيث تختار أضيق المنح المطلوبة بواسطة حمل العمل. -احفظ السر عند إنشاؤه؛ لن يتم عرضه مرة أخرى. قم بالتدوير بإنشاء بديل وتحديث المستهلك ثم تعطيل المفتاح القديم. + ![درج مفتاح API الجديد مع إعدادات الأذونات المسبقة والمنح الفردية.](/images/dashboard/key-create.png) -## مفاتيح الآلات + بعد الإنشاء، تعرض صفحة المفاتيح البيانات الوصفية الدائمة وإجراءات الإدارة. لن يتم عرض السرّ لمرة واحدة مرة أخرى. -يربط مفتاح الآلة الخدمة المحلية بالسحابة: + ![صفحة مفاتيح API توضح أذونات المفتاح ووقت الإنشاء وإجراءات إعادة التوليد والتعطيل.](/images/dashboard/api-keys.png) -```bash -export FAILPROOFAI_CLOUD_TOKEN="" -failproofai config -``` + استخدم هذه القائمة لمراجعة المنح بشكل منتظم وتعطيل المفاتيح التي لا تعود مرتبطة بحمل عمل نشط. + + + ```bash + fp keys create production-agents \ + --add events:add \ + --add policies:pull + fp keys show production-agents + fp keys update production-agents --add events:read + fp keys regenerate production-agents --yes + fp keys disable production-agents + ``` -قد تحتاج الآلة المتصلة إلى قدرتين: + أعد توجيه أو احصر مخرجات الإنشاء/إعادة التوليد بشكل آمن؛ يتم إرجاع السرّ مرة واحدة فقط. + + -- `policies:pull` لاستقبال السياسات المدارة من السحابة. -- `events:add` لإرسال القرارات والجلسات. +الأذونان المطلوبان بواسطة آلة Failproof AI متصلة مستقلان: -تقارير الحالة تقدم هذه بشكل منفصل لأن أحدهما قد يعمل بينما الآخر لا يعمل. +- `events:add` يرسل الأحداث وبيانات الجلسة. +- `policies:pull` يسترجع نشرات السياسات المعيّنة. -## الأذونات الشائعة +يتم عرض أسرار المفاتيح عند إنشاؤها أو إعادة توليدها. قم بتخزينها في مدير الأسرار وأدرها دون إعادة استخدام بيانات اعتماد المشغّل التفاعلية. -| الإذن | السماح به | +## كتالوج الأذونات + +| المجال | الأذونات | | --- | --- | -| `events:add` | إرسال الأحداث | -| `events:read` | قراءة الأحداث والأخطاء | -| `evaluations:read` | قراءة الجلسات والتقييمات | -| `audits:read` / `audits:write` | مراجعة أو إدارة التدقيقات | -| `policies:read` / `policies:write` | مراجعة أو نشر السياسات | -| `policies:pull` | سحب تعيينات سياسات الآلة | -| `keys:create` / `keys:disable` | إنشاء أو تعطيل المفاتيح | -| `orgs:admin` | إدارة المنظمة على مستوى المثيل؛ غير قابلة للتعيين لمفتاح تنظيمي | +| الأحداث | `events:add`, `events:read` | +| المفاتيح | `keys:create`, `keys:read`, `keys:disable`, `keys:regenerate`; `keys:update` متاح فقط للجلسات البشرية | +| المستخدمون | `users:create`, `users:read`, `users:update`, `users:delete` | +| التقييمات | `evaluations:read`, `evaluations:trigger` | +| لوحات المعلومات | `dashboards:read`, `dashboards:write`, `dashboards:delete` | +| الاستعلامات | `queries:read`, `queries:write`, `queries:delete`, `queries:run` | +| المساعد | `agent:use` | +| الإعدادات | `settings:read`, `settings:write` | +| التنبيهات | `alerts:read`, `alerts:write` | +| المشاكل | `issues:read`, `issues:create`, `issues:close` | +| عمليات التدقيق | `audits:read`, `audits:write` | +| السياسات | `policies:read`, `policies:write`, `policies:pull` | +| الاستخدام | `usage:read` | + +`orgs:admin` محفوظ لمشغّل النموذج ولا يمكن منحه لمفتاح منظمة أو عضو عادي. تقبل الرموز المتقاعدة `incidents:*` و `alerts:ack` من أجل التوافقية وتُعاد معايرتها إلى أذونات `issues:*` الحالية. -تتطلب بعض أوامر `fp fleet` و `fp guardrails` الإدارية جلسة مستخدم موقعة بدلاً من مفتاح API. يشير نص المساعدة فيها إلى ذلك قبل تقديم طلب. +مجموعات الأذونات المدمجة هي `read-only` و `standard` و `admin`. تضيف `standard` تفعيل التقييم وتنفيذ الاستعلامات والرد على المشاكل واستخدام المساعد إلى أذونات القراءة. يزيل إنشاء المفتاح المنح الخاصة بالبشر فقط حتى عندما تحتوي مجموعة الأذونات عليها. - لا تعد استخدام بيانات اعتماد الاستيعاب مثل `AGENTEYE_KEY` أو `AGENTEYE_API_KEY` كـ `FP_API_KEY`. فهي تخدم أنظمة وأذونات مختلفة. + يمكن لمفاتيح النطاق على مستوى النموذج تحديد منظمة باستخدام رأس `X-AgentEye-Org`. قم بتعيينها بشكل صريح على نشرات متعددة المنظمات؛ قد يؤدي الحذف إلى تحديد المنظمة الافتراضية. \ No newline at end of file diff --git a/docs/ar/admin/overview.mdx b/docs/ar/admin/overview.mdx index 76e9481d8..8bfcd1d87 100644 --- a/docs/ar/admin/overview.mdx +++ b/docs/ar/admin/overview.mdx @@ -1,30 +1,22 @@ --- title: "الإدارة" -description: "تشغيل وصول Cloud والعضوية والإعدادات والاستهلاك دون دمجها في سير عمل الموثوقية." +description: "تشغيل الوصول والاستخدام والمنظمات والأمان دون دمجها في سير عمل الموثوقية." icon: "settings-2" --- -الإدارة هي نصف Failproof AI في Cloud. المؤسسات والأعضاء ومفاتيح API وإعدادات المؤسسة والاستهلاك المقاس — كل هذا يتطلب اتصال Cloud. - - - يعمل Failproof AI أيضاً بدون حساب على الإطلاق. آلة محلية تفرض السياسة، وتحتفظ بسجل الجلسة على القرص، وتخدم لوحة المعلومات المحلية على `localhost:8020`، وتشغل `failproofai audit` دون إرسال أي شيء في أي مكان. اطلع على تكوين الآلة في [machine configuration](/ar/reference/events-and-configuration#machine-configuration) لمفاتيح `collector` المحلية. تخطَّ بقية هذا القسم إذا لم تكن تستخدم Cloud. - - -## حيث تقع الأدوات +تحتوي الإدارة على عناصر التحكم اللازمة لتشغيل Failproof AI عبر فريق. يمكن لمعظم المستخدمين البقاء في الجلسات والتدقيق والسياسات؛ يستخدم المسؤولون هذا القسم لإدارة الوصول وحدود التشغيل. - - مجموعة **admin** في شريط الجانب Cloud تحتوي على **محرر السياسة** و**الإنفاذ** و**الاستخدام** و**المفاتيح** و**المستخدمون** و**الإعدادات**. + + استخدم قسم **Admin** في الشريط الجانبي للسحابة للوصول إلى **محرر السياسات** و**الإنفاذ** و**الاستخدام** و**المفاتيح** و**المستخدمين** و**الإعدادات**. يشير العنصر المقفل إلى أن حسابك يفتقد إلى صلاحية القراءة. - ![مجموعة admin في شريط جانب Cloud يحتوي على محرر السياسة والإنفاذ والاستخدام والمفاتيح والمستخدمين والإعدادات.](/images/dashboard/admin-navigation.png) + ![قسم الإدارة في الشريط الجانبي للسحابة يعرض محرر السياسات والإنفاذ والاستخدام والمفاتيح والمستخدمين والإعدادات.](/images/dashboard/admin-navigation.png) - - ثبّت Cloud CLI كأداة منفصلة، ثم قم بتسجيل الدخول: - + ```bash - uv tool install fp-cloud-cli - fp login fp whoami + fp orgs current + fp orgs perms fp usage ``` @@ -32,43 +24,17 @@ icon: "settings-2" -## إنسان مسجل دخول أو مفتاح API - -يعمل `fp` في أحد وضعي المصادقة، والفاصل يحدد الأوامر التي تعمل. الأمر الذي لا يمكن لمفتاح API تنفيذه يرفض قبل فتح الاتصال ويسمي السبب، بدلاً من ترك 401 أو 403 يحل محله. - -| الأمر | مفتاح API | الإذن | -| --- | --- | --- | -| `fp whoami` | نعم | لا شيء | -| `fp usage` | نعم | `usage:read` | -| `fp keys list` / `show` | نعم | `keys:read` | -| `fp keys create` | نعم | `keys:create` | -| `fp keys disable` | نعم | `keys:disable` | -| `fp keys regenerate` | نعم | `keys:regenerate` | -| `fp keys update` | لا | `keys:update`، الذي لا يمكن لأي مفتاح أن يحتفظ به | -| `fp users list` / `show` | نعم | `users:read` | -| `fp users create` | نعم | `users:create` | -| `fp users update` | نعم | `users:update` | -| `fp users disable` / `enable` | نعم | `users:delete` | -| `fp settings list` / `schema` | نعم | `settings:read` | -| `fp settings set` | نعم | `settings:write` | -| `fp orgs list` / `switch` / `current` / `perms` | لا | جلسة مسجلة دخول فقط | - -`fp usage` هو الأمر الذي يجب إعطاؤه لسكريبت إعداد التقارير: يعمل دون مراقبة تحت مفتاح ويحتاج فقط `usage:read`. - - - أنشئ بيانات اعتماد الآلة، وامنح كل عملية فقط الأذونات التي تحتاجها. - - - أدِر العضوية، واحتفظ بنطاق بيانات كل مؤسسة وإجراءاتها. + + فحص نوافذ الفوترة واستهلاك المنظمة. - - عيّن قيم تسجيل الدخول والتنبيهات، وحدد بيانات الوكيل التي تغادر الآلة. + + منح الآلات والأتمتة الصلاحيات المطلوبة فقط. - - اقرأ ما قاست المؤسسة خلال نافذتها الحالية من 30 يوماً. + + إدارة العضوية والإعدادات الافتراضية وحدود المنظمة. - - انظر الآلات المسجلة والكيفية التي تُحدَّد بها وما تفرضه. + + تكوين إعدادات التشغيل ومعالجة البيانات وأمان النشر. \ No newline at end of file diff --git a/docs/ar/admin/settings-and-security.mdx b/docs/ar/admin/settings-and-security.mdx index 40abbcc67..b8c121dcd 100644 --- a/docs/ar/admin/settings-and-security.mdx +++ b/docs/ar/admin/settings-and-security.mdx @@ -1,38 +1,68 @@ --- ---- title: "الإعدادات والأمان" -description: "التحكم في إعدادات المؤسسة الافتراضية ومعالجة البيانات بيانات الاعتماد للآلة." -icon: "shield" +description: "قم بتكوين الإعدادات التشغيلية واتخذ قرارات مدروسة حول بيانات الوكيل." +icon: "lock-keyhole" --- -إعدادات المؤسسة تؤثر على الجميع في منظمة Cloud تلك. غيّرها من **Admin → settings** أو باستخدام `fp settings`. +استخدم الإعدادات للقيم التشغيلية الخاصة بالنشر وتجاوزات نافذة سياق النموذج. افحص مخطط الإعدادات قبل تغيير قيمة من خلال واجهة برمجية التطبيقات أو واجهة سطر الأوامر. + +## تغيير إعداد المؤسسة + + + + 1. انتقل إلى **Administration → Settings**، وابحث عن مجموعة الإعدادات، واقرأ وصفها والمصدر الحالي. + 2. غيّر القيمة واحفظها. + 3. بالنسبة لنوافذ سياق النموذج، أضف أو حدّث تجاوز النموذج وأكّد الحد الفعلي. + 4. أعد التحقق من الجلسات والمقاييس التي تعتمد على القيمة المتغيرة. + + ![صفحة الإعدادات تعرض إعدادات مصادقة المؤسسة والإعدادات التشغيلية.](/images/dashboard/settings.png) + + + ```bash + fp settings list + fp settings schema + fp settings set --value + fp settings set alerts.email_default_recipients \ + --json-value '["oncall@example.com"]' + ``` -```bash -fp settings list -fp settings set -``` + شغّل `fp settings set --help` للحصول على نوع القيمة وأعلام التأكيد المستخدمة بواسطة واجهة سطر الأوامر المثبتة. + + -## معالجة البيانات +## خيارات معالجة البيانات -الآلة المتصلة ترسل قرارات السياسة والنسخ الكاملة من جلسات العمل بشكل افتراضي. لإرسال القرارات فقط، اضبط `collector.sessions` على `false` في ملف `~/.failproofai/config.json` الخاص بالآلة بعد الاتصال. علم الإعداد الحالي `--no-transcripts` لا ينطبق على هذا الإعداد. +يؤدي توصيل Failproof AI CLI إلى إرسال النصوص الكاملة بشكل افتراضي لأن التتبعات والتدقيقات تعتمد على محتواها. استخدم `--no-transcripts` عندما يجب أن تبقى المطالبات أو محتويات الملفات أو إدخال الطرفية محلية؛ يمكن لا يزال الإبلاغ عن نشاط الخطاف وقرارات السياسة. -يتم حذف بيانات الاعتماد على الآلة قبل التحميل، لكن إزالة الالتباس هي الحد الأدنى للأمان وليست بديلاً عن التحكم بالوصول. +يتم تخزين بيانات اعتماد الإدخال المحلي بشكل منفصل عن إعدادات خادم غير سرية ويتم كتابتها بأذونات مقيدة. يجب بالتالي إدارة مفاتيح واجهة برمجية التطبيقات كأسرار الإنتاج. -الاستخدام المحلي فقط لا يتطلب حساباً. تاريخ الجلسة والتدقيق يبقى على الآلة، ما عدا التدقيق المحلي المجدول الذي يرسل هوية الآلة وملخص محدود بعد أن توافق عليه. يمكن تعطيل قياس الاستخدام المجهول للـ CLI باستخدام `FAILPROOFAI_TELEMETRY_DISABLED=1`. +## مرجع إعداد المؤسسة -## بيانات الاعتماد +جميع الإعدادات القابلة للتحرير في لوحة المعلومات لها نطاق تنظيمي. يبقى السلوك على مستوى النشر الكامل كتكوين بيئة الخادم. -رموز الآلة مخزنة تحت `~/.failproofai/` برأذونات تابعة للمالك فقط. لا يتم كتابتها في تعريف الخدمة. +| المفتاح | الافتراضي | الغرض | +| --- | --- | --- | +| `allowed_sign_ins` | `[]` | قيّد الأعضاء الحاليين إلى رسائل بريد إلكترونية دقيقة أو `*@domain`؛ القائمة الفارغة تعني عدم وجود تقييد إضافي. | +| `session_ttl_secs` | `86400` | مدة جلسة لوحة المعلومات؛ النطاق المقبول من 60 ثانية إلى 30 يومًا. | +| `otp_ttl_secs` | `600` | مدة OTP والرابط السحري؛ النطاق المقبول هو 60–1800 ثانية. | +| `alerts.email_default_recipients` | `[]` | المستلمون الافتراضيون عندما لا تتجاوز قناة البريد الإلكترونية للتنبيهات عنهم. | +| `alerts.slack_default_webhook` | فارغ | عنوان URL ويب هوك Slack الافتراضي. | +| `alerts.webhook_default_url` | فارغ | عنوان URL ويب هوك JSON عام افتراضي. | +| `alerts.webhook_signing_secret` | فارغ | مفتاح HMAC-SHA256 المستخدم لرأس `X-AgentEye-Signature`؛ القراءات مخفية. | +| `alerts.enabled_channels` | البريد الإلكترونية، Slack، ويب هوك | أنواع القنوات على مستوى المنظمة التي قد ترسل قواعد التنبيهات. | +| `default_user_permissions` | `standard` | مجموعة الأذونات المسماة المحددة مسبقًا للدعوات الجديدة. | -استخدم مفاتيح منفصلة للأشخاص والأتمتة والآلات. أعطِ كل واحدة الأذونات التي تحتاجها فقط، وأدرها عند تغيير الملكية، وألغِ إذنها عندما تتقاعد الآلة أو سير العمل. +`allowed_sign_ins` هو مرشح، وليس منح: يجب أن يكون الشخص بالفعل عضوًا في المنظمة. استخدم قائمة فارغة للسماح لكل عضو؛ القيمة المكررة `*` مرفوضة. يجب أن تستخدم عناوين URL للتنبيهات HTTPS باستثناء عناوين التطوير loopback. -## قائمة التحقق +## قائمة التحقق من الأمان -- اطلب أضيق أذونات مفيدة. -- اضبط `collector.sessions` على `false` حيث لا تكون محتويات كاملة ضرورية. -- راجع من يمكنه نشر السياسات الملزمة. -- اختبر السياسات في وضع المراقبة قبل التطبيق. -- اجعل تسميات الآلة واضحة ومعرّفات الآلة مستقرة. -- شغّل `failproofai config --status` بعد تغيير إعدادات الاتصال. +- استخدم HTTPS للاتصالات السحابية. +- حصّر المفاتيح على أصغر مجموعة أذونات. +- افصل بين بيئات الإنتاج وغير الإنتاج. +- راجع إعدادات التقاط والتحرير النصي قبل النشر. +- دقّق التغييرات في المستخدمين والمفاتيح والمنظمة. +- اختبر متطلبات النسخة الاحتياطية والاحتفاظ واستجابة الحوادث للنشر الخاص بك. -انظر [المفاتيح والأذونات](/ar/admin/keys-and-permissions) للحصول على كتالوج الأذونات. \ No newline at end of file + + إيقاف تشغيل التقاط النصي يغيّر ما يمكن للتدقيقات والتحقيقات أن تثبته. سجّل القرار والقيود المتوقعة منه. + \ No newline at end of file diff --git a/docs/ar/admin/usage.mdx b/docs/ar/admin/usage.mdx index 9492b39d6..bde9fa61c 100644 --- a/docs/ar/admin/usage.mdx +++ b/docs/ar/admin/usage.mdx @@ -1,78 +1,38 @@ --- --- title: "الاستخدام" -description: "فحص استهلاك المؤسسة للنافذة الحالية المدتها 30 يوماً." +description: "فحص استهلاك المؤسسة ونافذة الفواتير النشطة." icon: "chart-no-axes-combined" --- -يعرض الاستخدام ما قامت المؤسسة الحالية بقياسه خلال نافذة مدتها 30 يوماً. النافذة ثابتة ومرتبطة بكل مؤسسة، والاستخدام للقراءة فقط: لا ينطبق ولا يعرض أي حدود أو حصص أو عتبات خطة. كلا الواجهتين تشير إلى ذلك — لوحة سطر الأوامر تطبع "استخدام للقراءة فقط، لا توجد حدود مطبقة". +يعرض الاستخدام استهلاك المؤسسة الحالية ونوافذ الفواتير الخاصة بها. استخدمه لفهم كيفية تأثير نشر الإنتاج وحجم النصوص والتقييمات وتكرار التدقيق على خطتك. ## مراجعة الاستخدام - - 1. انتقل إلى **admin → usage**. - 2. أكّد المؤسسة والنافذة الزمنية — يعرض الرأس بداية ونهاية النافذة واليوم فيها والوقت المنقضي. - 3. اقرأ كتلة البطل: الأحداث المدرجة والجلسات والوكلاء والبيئات. - 4. اقرأ خطوط الأنابيب الاثنين: التقييمات (مع النقاط والمقاييس) والتدقيقات (مع المشاكل والتنبيهات)، كل منها يعرض الحالات المكتملة مقابل الحالات المبدوءة. - 5. اقرأ كتل مساحة العمل والوصول: الاستعلامات المحفوظة والبيانات والتنبيهات والمشاكل الفريدة والأعضاء ومفاتيح API. + + 1. انتقل إلى **الإدارة → الاستخدام**. + 2. تأكد من المؤسسة ونافذة القياس. + 3. راجع الاستيعاب والجلسات والتقييمات والمقاييس والتدقيقات والنتائج والتنبيهات والمستخدمين والمفاتيح. + 4. قارن عمل التدقيق الذي تم بدؤه واكتماله عندما يبدو استخدام التدقيق غير متوقع. - الأرقام مخزنة في الذاكرة المؤقتة وليست مباشرة. استخدم التحكم في التحديث في الأعلى يميناً بعد إجراء تتوقع أن ترى تأثيره. - - ![صفحة الاستخدام تعرض النافذة الزمنية والأحداث المستقطة وخطوط أنابيب التقييم والتدقيق وموارد مساحة العمل والأعضاء ومفاتيح API.](/images/dashboard/usage-overview.png) + ![صفحة الاستخدام تعرض نافذة القياس والأحداث المستقبلة وخطوط أنابيب التقييم والتدقيق وموارد مساحة العمل والأعضاء ومفاتيح واجهة برمجة التطبيقات.](/images/dashboard/usage-overview.png) - + ```bash fp usage fp --json usage fp --org reliability-team --json usage ``` - - يحتاج `fp usage` إلى `usage:read` ويعمل تحت مفتاح API، مما يجعله الأمر المناسب لـ cron التقارير. - - مع `--json` يعيد استجابة لوحة البيانات دون تغيير: `org_id` و `billing_anchor` و `window` و `usage` و `calculated_at` و `stale_after`. `calculated_at` و `stale_after` هما كيفية معرفة قدم الرقم. - - لا يأخذ `fp usage` أي أعلام خاصة به — فقط `--json` و `--org` العامة. يقارير النافذة الحالية فقط وليس شيء قبلها، لذا احتفظ بسجلك الخاص بتشغيله بجدول زمني وتخزين حمولة `--json` بدلاً من توقع الاستعلام عن نافذة سابقة لاحقاً. - - ```bash - fp --json usage | jq '.usage.events_ingested' - ``` -### مفاتيح المقاييس - -كل شيء تحت `usage` في حمولة JSON، لذا يمكن لبرنامج نصي أن يسمي حقلاً بدلاً من تحليل لوحة. - -| المجموعة | المفاتيح | -| --- | --- | -| بيانات المراقبة | `events_ingested` و `sessions` و `agents` و `environments` | -| التقييمات | `evaluation_runs` و `evaluation_finishes` و `evaluations` و `metrics` | -| التدقيقات | `audit_runs` و `audit_finishes` و `issues_created` و `alerts_created` | -| مساحة العمل | `queries_created` و `dashboards_created` | -| الوصول | `users_active` و `users_created` و `keys_active` و `keys_created` | - -تقارير كل خط أنابيب العد المبدوء والمكتمل بشكل منفصل، لذا فإن الفجوة بين `audit_runs` و `audit_finishes` تعني عملاً بدأ ولم ينته — يستحق التحقق قبل أن تقرأ أي شيء في عدد المشاكل تحته. - -## التحقق من التغيير - -يتم تحديد حجم البيانات المدرجة لكل آلة وليس بشكل مركزي. ابدأ من المؤسسة والنافذة، ثم تابع ما تغير على الآلات التي تقدم البيانات إليها. - -| السبب | مكان التحقق | ما يجب تغييره | -| --- | --- | --- | -| آلة تقوم بإرسال نصوص الجلسة | `collector.sessions` في `~/.failproofai/config.json` لتلك الآلة | اضبطها على `false` لإرسال القرارات فقط | -| يتم إرسال نشاط الخطاف بالكامل | `collector.hooks_verbosity` في نفس الملف | `decisions` يسمح بالتجميع كل دقيقة؛ `off` يوقف أحداث الخطاف تماماً | -| تمت إضافة موقع التقاط جديد | `failproofai harness list` | أزله باستخدام `failproofai harness remove-path ` | -| تم إعادة إرسال السجل | عمليات `failproofai backfill` للآلة | تقوم بإعادة الإرسال بإزالة التكرار على تجزئة المحتوى والانهيار في الصفوف الموجودة بالفعل، لذا لا تعد مزدوجة | -| بدأت تكامل جديد في الإبلاغ | عدد `agents` و `environments` وقائمة الجلسات | حدد نطاق إعدادات المجمع للآلة الجديدة قبل طرحها | +## التحقيق في التغيير -الاستخدام لا يقارن شيئاً مقابل خطة. افعل ذلك خارج المنتج. +1. تأكد من المؤسسة ونافذة النشاط. +2. قارن الزيادة مع حجم الجلسات حسب البيئة. +3. تحقق مما إذا بدأت عملية دمج جديدة في إرسال النصوص. +4. راجع تغييرات التقييم وتكرار التدقيق. +5. قارن مقابل الحدود على خطة التسعير الحالية. - - - إعدادات التعامل مع البيانات لكل آلة خلف هذه الأرقام. - - - سطح `fp` الكامل، بما في ذلك التثبيت والدخول. - - \ No newline at end of file +تعيد واجهة سطر الأوامر نفس الملخص للسكريبتات. \ No newline at end of file diff --git a/docs/ar/admin/users-and-organizations.mdx b/docs/ar/admin/users-and-organizations.mdx index 188d3f215..0ce50af87 100644 --- a/docs/ar/admin/users-and-organizations.mdx +++ b/docs/ar/admin/users-and-organizations.mdx @@ -1,16 +1,21 @@ --- -title: "المستخدمون والمنظمات" -description: "تحكم في العضويات واحفظ بيانات وإجراءات كل منظمة في نطاق محدد." +title: "المستخدمون والمؤسسات" +description: "التحكم في العضوية والحفاظ على نطاق بيانات وإجراءات كل مؤسسة." icon: "users" --- -تعزل المنظمات الجلسات والتقييمات والتدقيقات والمشاكل والتنبيهات والاستعلامات وجداول المعلومات والمستخدمين والمفاتيح. تأكد من المنظمة النشطة قبل تغيير أي مورد إداري. +تعزل المؤسسات الجلسات والتقييمات والتدقيقات والمشاكل والتنبيهات والاستعلامات لوحات المعلومات والمستخدمين والمفاتيح. تأكد من المؤسسة النشطة قبل تغيير الموارد الإدارية. -## اختيار المنظمة +## إدارة الأعضاء والمؤسسات - - استخدم محدد المنظمة في أعلى شريط الجانب في السحابة. كل ما يليه — بما في ذلك كل صفحة في **admin** — يقرأ ويكتب إلى هذه المنظمة. + + 1. استخدم محول المؤسسة في أعلى الشريط الجانبي للسحابة لتبديل المؤسسات. + 2. انتقل إلى **Administration → Users** للبحث عن الأعضاء أو التصفية حسب حالة النشاط والدور. + 3. حدد **new user**، وأدخل البريد الإلكتروني، واختر مجموعة أذونات، وعدّل الاستثناءات إذا لزم الأمر. + 4. افتح مستخدماً لاحقاً لتحديث المنح أو تعطيل تسجيل الدخول أو إعادة تفعيل الحساب. + + ![صفحة Users تعرض عناوين بريد الأعضاء ومجموعات الأذونات وعناصر التحكم في التحرير والتعطيل.](/images/dashboard/users.png) ```bash @@ -18,62 +23,22 @@ icon: "users" fp orgs switch reliability-team fp orgs current fp orgs perms - ``` - - `fp orgs switch` بدون معرف يفتح منتقي أسهم يبدأ من منظمتك الحالية؛ التشغيل غير التفاعلي يعود إلى طلب مرقم، وتحت `--json` يلزم معرف. يستمر الاختيار إلى `~/.failproofai/fpcli/cli-auth.json`، لذا تُرسل الأوامر اللاحقة المستأجر النشط. تجاوزه لأمر واحد باستخدام `--org ` أو `FP_ORG`. - - - - - كل أمر `fp orgs` يحتاج إلى شخص موقع ويرفض تحت مفتاح API، لأن عضوية المنظمة تنتمي إلى شخص والمفتاح يعمل بالفعل لمنظمة واحدة. أوامر `fp users` أدناه تعمل بكلا الطريقتين. - - -## إدارة الأعضاء - - - - 1. انتقل إلى **admin → users** وابحث عن الأعضاء حسب البريد الإلكتروني، أو ضيّق القائمة باستخدام شرائح الفلتر `protected` و `admin` و `standard` و `read-only`. - 2. اختر **new user**، أدخل البريد الإلكتروني، اختر مجموعة الأذونات، وأضبط التجاوزات الخاصة بكل عضو إذا لزم الأمر. - 3. افتح عضواً لاحقاً لتغيير الأذونات أو تعطيل تسجيل الدخول أو إعادة تفعيل الحساب. - ![صفحة المستخدمين مع صندوق البحث بالبريد الإلكتروني وشرائح الفلتر وبطاقة عضو توضح أذوناته مجمعة حسب المورد.](/images/dashboard/users.png) - - شرائح الأذونات في هذا الإطار أسبق من إعادة تسمية `incidents:*` إلى `issues:*`؛ قائمة [الأذونات الشائعة](/ar/admin/keys-and-permissions#common-permissions) محدثة. - - - ```bash - fp users list - fp users list --active-only fp users create engineer@example.com --permission-set standard fp users show engineer@example.com fp users update engineer@example.com --add audits:write fp users disable engineer@example.com fp users enable engineer@example.com ``` - - يتم توجيه الأعضاء بالبريد الإلكتروني وحلهم بعدم الحساسية لحالة الأحرف، لذا `fp users show Alice.Chen@Example.com` و `fp users create alice.chen@example.com` يشيران إلى نفس الشخص. -### الأذونات وما يحتاجه كل فعل - -تستخدم أذونات الأعضاء نفس الحساب مثل المفاتيح: الأذونات الفعلية هي `(set ∪ added) − removed`، و `--add` / `--remove` تأخذ رموز `slug:action.action` المختصرة حيث تتسع الإجراءات المنقوطة. انظر [المفاتيح والأذونات](/ar/admin/keys-and-permissions). - -| الفعل | الأذونة | ملاحظات | -| --- | --- | --- | -| `fp users list` / `show` | `users:read` | `--active-only` يخفي الأعضاء المعطلين. | -| `fp users create` | `users:create` | `--permission-set` يعين الدور؛ `--add` / `--remove` يطبقان تجاوزات. | -| `fp users update` | `users:update` | `--permission-set` **يستبدل** تجاوزات العضو الخاصة به؛ `--add` / `--remove` وحدهما متزايدان مقابل أذوناته الحالية. | -| `fp users disable` / `enable` | `users:delete` | كلاهما، بما في ذلك التفعيل — منح هذا بشكل مقصود. | - -يرفض التعطيل حالتين بشكل مباشر، كخطأ Forbidden وليس رسالة تحقق: لا يمكن تعطيل عضو **protected**، ولا يمكنك تعطيل حسابك الخاص. تعطيل عضو معطل بالفعل، أو تفعيل عضو نشط بالفعل، هو عدم تدخل هادئ. تستخدم API عملية حذف للتعطيل، لكنها لا تزيل الحساب أو سجل العضوية. - -تحكم إعدادات منظمتين في العضوية: `default_user_permissions` يحدد مجموعة الأذونات للدعوة الجديدة، و `allowed_sign_ins` يتحكم في العناوين التي يمكنها تلقي رمز تسجيل دخول. أدرها من [صفحة الإعدادات](/ar/admin/settings-and-security). +يمكن للمسؤولين إنشاء وتحديث وتعطيل وإعادة تفعيل المستخدمين، ثم تعيين مجموعة الأذونات المناسبة لدورهم. يستخدم API عملية حذف للتعطيل، لكنها لا تزيل الحساب أو سجل عضويته. - تعطيل مستخدم يمنع هذه الهوية من تسجيل الدخول إلى كل منظمة، وليس فقط المنظمة المحددة حالياً. إعادة التفعيل تستعيد تسجيل الدخول العام وأذونات العضو في هذه المنظمة. + يؤدي تعطيل مستخدم إلى منع هذه الهوية من تسجيل الدخول إلى كل مؤسسة، وليس فقط المؤسسة المحددة حالياً. يستعيد إعادة التفعيل تسجيل الدخول العام وأذونات العضو في هذه المؤسسة. - أعط حسابات الخدمة أسماء وصفية مرتبطة بسير عمل والمالك. لا تشارك مفتاحاً بين المنظمات، أو بين شخص وآلة. + أعطِ حسابات الخدمة أسماء وصفية مرتبطة بعبء العمل والمالك. تجنب مشاركة المفاتيح بين المؤسسات أو بين الأشخاص والآلات. \ No newline at end of file diff --git a/docs/ar/audits/alerts.mdx b/docs/ar/audits/alerts.mdx index f0eacd434..1442287d5 100644 --- a/docs/ar/audits/alerts.mdx +++ b/docs/ar/audits/alerts.mdx @@ -1,104 +1,63 @@ --- --- title: "التنبيهات" -description: "كشف التكرار وتوجيه المشكلة إلى المستجيبين المناسبين." +description: "كتشف تكرار الحادثة وأرسلها إلى المستجيبين المناسبين." icon: "bell-ring" --- -يراقب التنبيه حالة قابلة للقياس ويفتح مشكلة عند تفعيله. استخدمه عندما يجب أن ينتج عن الفشل استجابة فورية، سواء كانت السياسة قادرة على حجبه أم لا. +تراقب التنبيهات حالة قابلة للقياس وتنشئ حادثة عندما تنطلق. استخدمها عندما يجب أن ينتج عن الفشل استجابة في الوقت المناسب، بغض النظر عما إذا كانت السياسة يمكنها حجبه أم لا. ## إنشاء واختبار تنبيه - 1. انتقل إلى **Analyze → Alerts** واختر **new alert**. يمكنك أيضًا البدء من أيقونة الجرس على خطأ تمثيلي. + 1. انتقل إلى **Analyze → Alerts** واختر **new alert**. يمكنك أيضًا البدء من رمز الجرس على خطأ تمثيلي. 2. أدخل الاسم والخطورة ونوع المشغل والشرط وفترة التقييم وعدد الانتهاكات والنافذة والقنوات. - 3. احفظ التنبيه وافتح صفحة التفاصيل الخاصة به وشغّل **test**. - 4. انتقل إلى **Analyze → Issues** للإقرار والتعيين والمناقشة والاشتراك في المشاكل التي يفتحها التنبيه وحلها. + 3. احفظ التنبيه وافتح صفحة التفاصيل الخاصة به وقم بتشغيل **test**. + 4. انتقل إلى **Analyze → Issues** للقبول والتعيين والنقاش والاشتراك والتحقق من الحوادث التي أنشأها التنبيه. - يحدد الجزء الأول من النموذج التنبيه والإشارة التي يجب أن تفعله. + يحدد الجزء الأول من النموذج التنبيه والإشارة التي يجب أن تشغله. - ![الجزء الأول من نموذج new-alert مع اسمه وحالته المفعلة ونوع المشغل.](/images/dashboard/alert-new-trigger.png) + ![الجزء الأول من نموذج التنبيه الجديد مع اسمه وتفاصيله وحالة التفعيل ونوع المشغل.](/images/dashboard/alert-new-trigger.png) - يتحكم الجزء الثاني في المدة التي يجب أن يستمر الشرط فيها، وعدد مرات تقييمه، وأين يتم إرسال الإخطارات. + يتحكم الجزء الثاني في مدة استمرار الحالة وعدد مرات تقييمها وحيث يتم إرسال الإخطارات. - ![الجزء الثاني من نموذج new-alert مع منطق الانتهاك والجدول والخطورة وقنوات التسليم وإجراء الإنشاء.](/images/dashboard/alert-new-routing.png) + ![الجزء الثاني من نموذج التنبيه الجديد مع منطق الانتهاك والجدول والخطورة وقنوات التسليم وإجراء الإنشاء.](/images/dashboard/alert-new-routing.png) - بعد الحفظ، استخدم قائمة التنبيهات للتأكد من تفعيل القاعدة وأن المشغل والنافذة والخطورة والقنوات تطابق ما قصدته. تُظهر البطاقة التي تحتوي على مشاكل مفتوحة العدد؛ تحذف البطاقة بدون مشاكل هذا السطر تمامًا، لذا غيابها لا يخبرك بشيء. لقراءة الرقم لكل قاعدة بما في ذلك الأصفار، استخدم `fp alerts show `، والذي يطبعها دائمًا. + بعد الحفظ، استخدم قائمة التنبيهات للتأكد من تفعيل القاعدة وأن مشغلها ونافذتها وخطورتها وقنواتها تطابق ما كنت تقصده. - ![صفحة التنبيهات تعرض قواعس التنبيهات مع المشغلات ونوافذ التقييم والقنوات والخطورة.](/images/dashboard/alerts.png) + ![صفحة التنبيهات تعرض قواعس التنبيهات مع مشغلاتها وفترات التقييم والقنوات والخطورة.](/images/dashboard/alerts.png) + + اختبر التنبيه قبل الاعتماد عليه للاستجابة الإنتاجية. - + ```bash fp alerts create high-errors \ --trigger-kind metric_threshold \ --severity warning \ - --trigger-spec '{"metric":"error_count","op":">","value":50,"window_secs":900}' \ - --eval-interval-secs 300 \ - --min-breaches 2 \ - --eval-window 3 + --trigger-spec '{"metric":"error_count","op":">","value":50,"window_secs":900}' fp alerts show high-errors fp alerts test high-errors fp alerts update high-errors --severity critical --yes ``` - تبدأ التنبيهات الجديدة **مفعلة**، ويتم رفض تضارب الأسماء قبل إنشاء أي شيء. - - يستبدل `fp alerts update` التعريف الكامل من جانب الخادم، لذا يقرأ CLI التنبيه ويضع أعلامك فوقه — يحتاج التحديث الذي يحتوي على أعلام فقط على `alerts:read` **بالإضافة إلى** `alerts:write`، ويؤكد إلا إذا مررت `--yes`. - - استخدم `fp alerts list` لمراجعة القواعد و `fp alerts delete ` لإزالة واحدة. يعاين الحذف القاعدة — بما في ذلك عدد المشاكل المفتوحة — ويؤكد قبل التصرف، لأنه لا يمكن التراجع عنه. - - الحذف ليس الطريقة لتسكيت قاعدة مزعجة. `DELETE /alerts/{id}` يتسلسل: كل مشكلة فتحتها التنبيهات تذهب معها، تأخذ تعليقاتها والمشتركين وسجل النشاط. صندوق تأكيد CLI يعبر عن هذا بأن المشاكل المفتوحة يتم "حذفها بدون مالك"؛ عقد API هو حذف متسلسل، لذا تعامل مع السجل على أنه ذهب. لإيقاف تشغيل قاعدة والاحتفاظ بما سجلته، قم بإيقاف تشغيلها بدلاً من ذلك — نموذج التنبيهات على لوحة التحكم يحتوي على تبديل مفعّل، و لا يكشف `fp alerts create` و `fp alerts update` عن علم `--enabled`، لذا فإن مسار CLI هو `fp alerts update --file` مع تعريف كامل يحمل `enabled: false`. + استخدم `fp alerts list` لمراجعة القواعد و `fp alerts delete ` لحذف واحدة. - راجع [مرجع `fp alerts`](/ar/reference/cloud-cli#alerts) للحصول على مجموعة أوامر التنبيهات الكاملة. + اطلع على مرجع [`fp alerts`](/ar/reference/cloud-cli#alerts) للحصول على مجموعة أوامر التنبيه الكاملة. - - **test** يسلم إخطارات حقيقية. يرسل إلى قنوات البريد الإلكتروني و Slack والـ webhook الحقيقية للتنبيه ويفتح مشكلة اصطناعية، لذا يمكن أن ينبه من هو في الخدمة. يؤكد أولاً على محطة طرفية تفاعلية؛ `--yes` و `--json` و stdin المعاد توجيهه جميعًا يتخطون هذا الموجه. يبلغ الخادم أيضًا عن النجاح بمجرد التوزيع، لذا فإن الاختبار الأخضر يثبت أن الرسالة غادرت، وليس أنها وصلت. - - -## حدد المشغل - -هناك خمسة أنواع مشغلات: - -| `--trigger-kind` | يتفعل عندما | -| --- | --- | -| `metric_threshold` | تتجاوز مقياس حد معين — الأخطاء أو زمن الاستجابة أو التكلفة أو أي شيء آخر يمكنك قياسه. | -| `per_event` | يصل حدث مطابق واحد. | -| `evaluation_score` | تتجاوز درجة المقيّم حد معين. | -| `eval_compound` | يتم دمج عدة شروط درجات، مثل فشل اثنين من ثلاث درجات. | -| `custom_sql` | تُرجع استعلام تكتبه انتهاكًا. | +يمكن أن تكون شروط التنبيه مبنية على الأخطاء أو درجات التقييم أو تركيبات التقييم أو SQL مخصص. أضف المستقبلين واختبر القاعدة وافتح الحادثة الناتجة للقبول والتعيين والتعليق والاشتراك والتحقق منها. -يذهب الشرط نفسه إلى `--trigger-spec`، مشكل للنوع الذي اخترته. - -## ضبط أرقام التقييم - -تطلب نموذج لوحة التحكم و CLI نفس القيم الأربع. - -| الإعداد | العلم | القيم المقبولة | -| --- | --- | --- | -| الخطورة | `--severity` | `info`, `warning`, `critical` | -| فترة التقييم | `--eval-interval-secs` | 30–86,400 ثانية | -| عدد الانتهاكات | `--min-breaches` | واحد على الأقل، وليس أبدًا أكثر من النافذة | -| نافذة التقييم | `--eval-window` | واحد على الأقل، محسوبة بـ **intervals**، وليس بالثواني | - -لذا فإن `--eval-interval-secs 300 --min-breaches 2 --eval-window 3` يعني "قيّم كل خمس دقائق، وتفعّل عندما يكون اثنان من آخر ثلاث تقييمات قد انتهكا". - -## تصميم التنبيهات الجيدة +## تصميم التنبيه الجيد - سمّ الحالة وسير العمل المتأثر. -- حدد البيئة بوضوح. -- ضع نافذة وحد يتجنب الرد على حدث واحد ضار. -- أضف ارتباط أو استعلام يوجه المستجيبين إلى الجلسات. +- حدد البيئة بشكل صريح. +- عيّن نافذة وحد يتجنب الاستجابة لحدث واحد غير ضار. +- أضف رابطًا أو استعلامًا يقود المستجيبين إلى الجلسات. - عيّن مالكًا قبل تفعيل القاعدة. -- تحقق من `fp alerts show ` من عدد المشاكل المفتوحة قبل إضافة قاعدة أخرى للأعراض نفسها. تطبع بطاقة لوحة التحكم هذا السطر فقط عندما يكون العدد غير صفر. - بعد حل نتيجة تدقيق، أضف تنبيهًا عندما يمكن أن يحدث نفس الفشل خارج تغطية السياسة. - - - - الإقرار والتعيين والتعليق والاشتراك والحل — سير العمل الذي ينزل فيه كل تنبيه متفعل. - \ No newline at end of file + بعد حل نتيجة التدقيق، أضف تنبيهًا عندما قد يحدث نفس الفشل مرة أخرى خارج تغطية السياسة. + \ No newline at end of file diff --git a/docs/ar/audits/cadence.mdx b/docs/ar/audits/cadence.mdx index b97c6ddb0..1b468c8a0 100644 --- a/docs/ar/audits/cadence.mdx +++ b/docs/ar/audits/cadence.mdx @@ -1,29 +1,27 @@ --- -title: "دورة التدقيق" +title: "تكرار التدقيق" description: "اختر متى يتم تشغيل التدقيقات المتكررة وكمية البيانات التي تراجعها." icon: "calendar-clock" --- -استخدم التدقيقات المتكررة لأنماط الفشل التي قد تظهر مجددًا مع تغير الوكلاء والمحفزات والأدوات والنماذج. +استخدم التدقيقات المتكررة لأنماط الأعطال التي يمكن أن تعود مع تغير الوكلاء والمطالبات والأدوات والنماذج. -## تغيير الجدول الزمني +## غيّر الجدول الزمني 1. انتقل إلى **Analyze → Audits** وافتح التدقيق. - 2. اختر **edit settings** وغيّر الدورة والنافذة والحساسية أو عدد النتائج في كل تشغيل. - 3. احفظ التدقيق وأكّد وقت التشغيل التالي في رأس التدقيق. - 4. توقف واستأنف الجدول الزمني من نفس الرأس، بجانب **run now**. - 5. استخدم **run now** مرة واحدة بعد تغيير كبير في النطاق أو السياق. + 2. افتح إعداداته وغيّر حالة التفعيل أو الفترة الزمنية أو إرساء التوقيت العالمي أو وضع النافذة أو المراجعة للخلف. + 3. احفظ التدقيق وأكّد وقت التشغيل التالي على بطاقة التدقيق. + 4. استخدم **run now** مرة واحدة بعد تغيير النطاق أو السياق الرئيسي. - ![رأس تدقيق يعرض حالة الإيقاف المؤقت والنتائج المفتوحة والتشغيل الأخير والتشغيل التالي ونافذة المسح والحساسية وعناصر التحكم run now و edit settings و resume.](/images/dashboard/audit-detail.png) + ![محرر التدقيق يعرض التكرار ونافذة الكسح والنطاق وإعدادات التحليل والسياق وقنوات الإخطار.](/images/dashboard/audit-edit.png) ```bash fp audits edit checkout-reliability \ --schedule-interval-secs 86400 \ --schedule-anchor 2026-08-15T09:00:00Z \ - --window-mode since_last \ --lookback-window-secs 86400 \ --yes @@ -31,50 +29,21 @@ icon: "calendar-clock" fp audits edit checkout-reliability --enabled --yes ``` - يطلب `fp audits edit` تأكيدًا قبل تغيير أي شيء، ولهذا يمرر كل مثال هنا `--yes`. يستبدل الخادم التعريف بالكامل في كل تحرير، لذا تعيد CLI إرسال التدقيق الحالي مع تطبيق التغييرات — يحتاج التحرير الذي يتضمن الأعلام فقط إلى `audits:read` **وكذلك** `audits:write`. حدّد نطاق مفتاح CI لكليهما. - - انظر [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لحدود الجدول الزمني وسلوك النافذة وجميع أوامر التدقيق. + انظر إلى [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لحدود الجدول الزمني وسلوك النافذة وجميع أوامر التدقيق. -## حدا الجدول الزمني - -كل التوصيات أدناه يجب أن تناسب داخل هذه الحدود. النطاقات من الخادم، و`fp` يعكسها على الجانب الضيف، لذا القيمة خارج أحدها تخرج 2 محليًا بدلاً من أن تكلف جولة 422. - -| الحقل | العلم | النطاق | الافتراضي | -| --- | --- | --- | --- | -| فترة الجدول الزمني | `--schedule-interval-secs` | 3,600–604,800 ثانية (ساعة واحدة إلى 7 أيام) | 86,400 (يومي) | -| نافذة الاسترجاع | `--lookback-window-secs` | 3,600–7,776,000 ثانية (ساعة واحدة إلى 90 يومًا) | 604,800 (7 أيام) | - -سبعة أيام هي الحد الأقصى للدورة. لا يوجد تدقيق شهري في Cloud. +اختر التكرار بناءً على سرعة وتكلفة المخاطرة: -## اختر دورة - -اختر من سرعة وتكلفة المخاطر: - -| نمط المخاطر | دورة البداية | +| نمط المخاطرة | التكرار الأولي | | --- | --- | -| إجراء الإنتاج عالي التأثير | يومي، أو كل ساعة أثناء توجيه تغيير محفوف بالمخاطر | -| تراجع سير العمل أو النموذج | أسبوعي | -| مراجعة الحوكمة أو الوصول | أسبوعي — أطول فترة متاحة | - -وازن نافذة الاسترجاع مع الدورة حتى لا تترك التشغيلات فجوات ولا تفحص مجموعة سكانية كبيرة بلا داع بشكل متكرر. - -لا يوجد تدقيق لمرة واحدة؛ كل تدقيق يحمل فترة جدول زمني. للتحقيق من الإصدار، أنشئه مفعلاً، اترك التشغيل الأول ينطلق — يتم وضع التشغيل الأول في الطابور فورًا عند الإنشاء، بغض النظر عن الهدف — ثم أوقفه مؤقتًا باستخدام `fp audits edit --disabled --yes`. أعد التفعيل قبل استخدام **run now**: التدقيق المعطل ليس لديه صف قائمة انتظار، والتشغيل اليدوي عليه سيتم رفضه برمز 409. - -## وضع النافذة والهدف - -يقرر `--window-mode` نافذة كل تشغيل يقوم بمسحها: - -| الوضع | السلوك | -| --- | --- | -| `since_last` | المتابعة من نهاية النافذة المحللة بالكامل الأخيرة، لذا يترك التشغيل المتخطى بدون فجوة. | -| `fixed` | أعد فحص `lookback_window_secs` المتجدد في كل تشغيل، مهما كان ما غطاه التشغيل الأخير. | - -`--schedule-anchor` يثبت المرحلة بدلاً من التكرار: تهبط التشغيلات على `anchor + N × interval`. أغفله والهدف الافتراضي هو 09:00 UTC التالي؛ يتم رفض هدف أكثر من 365 يومًا. يدخل تغيير الفترة أو الهدف حيز التنفيذ في إعادة الجدولة التالية، وليس في التشغيل المصفوف بالفعل، والتشغيل الفاشل لا يحرك الهدف. +| إجراء الإنتاج عالي التأثير | يومي | +| انحدار سير العمل أو النموذج | أسبوعي | +| مراجعة الحوكمة أو الوصول | شهري | +| تحقيق إصدار لمرة واحدة | تشغيل مرة واحدة | -بعد تغيير هدف التدقيق أو سياقه، قم بتشغيله يدويًا مرة واحدة قبل الاعتماد على النتيجة المجدولة التالية. +قم بمواءمة نافذة المراجعة للخلف مع التكرار بحيث لا تترك التشغيلات فجوات ولا تفحص مجموعة سكانية كبيرة بلا داع بشكل متكرر. بعد تغيير هدف التدقيق أو سياقه، قم بتشغيله يدويًا مرة واحدة قبل الاعتماد على النتيجة المجدولة التالية. - هذه الصفحة تتعلق بجداول تدقيق Cloud، التي تعمل على جلسات Cloud. التدقيق المحلي لديه مؤقت خاص به: `failproofai audit --schedule [days]` يأخذ 1–90 يومًا والافتراضي 7، ويمسح تاريخ الوكيل على تلك الآلة الواحدة، وهو السطح الوحيد مع خيار شهري. النتائج والملكية منفصلة عن أي شيء هنا — انظر [Audit local agent history](/ar/audits/local-audit). + يتم تكوين التدقيقات المجدولة المحلية على الجهاز وتفحص سجل الوكيل المحلي. جداول التدقيق السحابية تعمل على جلسات السحابة. تعامل مع نتائجها وملكيتها بشكل منفصل. \ No newline at end of file diff --git a/docs/ar/audits/findings-and-issues.mdx b/docs/ar/audits/findings-and-issues.mdx index b04bb857a..ae002177a 100644 --- a/docs/ar/audits/findings-and-issues.mdx +++ b/docs/ar/audits/findings-and-issues.mdx @@ -1,137 +1,94 @@ --- --- title: "النتائج والمشاكل" -description: "حوّل أدلة التدقيق إلى عمل إصلاح مملوك وقابل للتتبع." +description: "حول أدلة التدقيق إلى عمل معالجة مملوك وقابل للتتبع." icon: "clipboard-check" --- -النتيجة هي البيان المدعوم بالأدلة من التدقيق حول فشل ما. المشكلة هي سير العمل الدائم للاستجابة لها. +النتيجة هي البيان المدعوم بالأدلة من التدقيق حول فشل ما. المشكلة هي سير العمل الدائم للرد عليها. -يستخدم الكائنان مفردات مختلفة، وهما يقفان بجانب بعضهما البعض، لذا يستحق الأمر توضيح الفرق بينهما أولاً: - -| | النتيجة | المشكلة | -| --- | --- | --- | -| الحالات | `open`, `recurring`, `resolved`, `dismissed`, `muted` | `firing`, `acknowledged`, `resolved` | -| علم التصفية | `--status` | `--state` | -| المعرّف | معرّف النتيجة | معرّف المشكلة | -| الإدراج الافتراضي | المجموعة النشطة: مفتوحة وحالات متكررة | الأحدث مفتوحة أولاً | - -## فرز العمل وإسناده +## فرز وإسناد العمل - - 1. افتح **Analyze → Audits**، واختر عملية اكتملت، ثم حدد نتيجة للفحص تفصيلاً تحليلها وتوصياتها والجلسات واستعلامات الأدلة. - 2. اعترف بالنتيجة، أو أسندها، أو أرفضها، أو أكتمها، أو حلها، أو أعد فتحها بعد التحقق من أدلتها. - 3. انتقل إلى **Analyze → Issues** وصفّ صندوق الوارد الدائم حسب الحالة أو الخطورة أو المسؤول. - 4. افتح المشكلة لإسنادها وإضافة تعليقات أو مشتركين، ثم حلها بعد التحقق من الإصلاح. + + 1. افتح **تحليل → التدقيقات**، اختر جولة مكتملة، ثم حدد نتيجة لفحص تحليلها والتوصية والجلسات واستعلامات الأدلة. + 2. أقرّ أو أسند أو ارفض أو أسكت أو حل أو أعد فتح النتيجة بعد التحقق من أدلتها. + 3. انتقل إلى **تحليل → المشاكل** وصفّ صندوق الوارد الدائم حسب الحالة أو الخطورة أو المسؤول. + 4. افتح المشكلة لإسنادها وإضافة تعليقات أو مشتركين، وحلّها بعد التحقق من الإصلاح. - ابدأ بملخص النتيجة. تأكد من أن وصف الفشل والاستجابة الموصى بها والخطورة والترتيب تتطابق مع الجلسات التي توقعت أن يفحصها التدقيق. + ابدأ بملخص النتيجة. تأكد من أن وصف الفشل والاستجابة الموصى بها والخطورة والترتيب تتفق مع الجلسات التي توقعت أن يفحصها التدقيق. - ![نتيجة تدقيق مع الخطورة وعدد الحالات والتحليل الجذري والإجراء الموصى به وعوامل الترتيب والأدلة.](/images/dashboard/audit-finding.png) + ![نتيجة تدقيق تعرض الخطورة وعدد الحدوث وتحليل السبب الجذري والإجراء الموصى به وعوامل الترتيب والأدلة.](/images/dashboard/audit-finding.png) - بعد ذلك، افتح جلسة متأثرة بدلاً من القرار من الملخص وحده. يجب أن يُظهر التتبع المرتبط الحدث الدقيق والحمل الفعلي الذي يدعم النتيجة. + بعد ذلك، افتح جلسة متأثرة بدلاً من الاعتماد على الملخص وحده. يجب أن يظهر التتبع المرتبط الحدث الدقيق والحمل الذي يدعمان النتيجة. - ![جلسة مرتبطة من نتيجة تدقيق، مفتوحة في الخطأ ذي الصلة مع بيانات الحدث والحمل الخام.](/images/dashboard/audit-linked-session.png) + ![جلسة مرتبطة من نتيجة تدقيق، مفتوحة في الخطأ ذي الصلة مع بيانات وصفية الحدث والحمل الخام.](/images/dashboard/audit-linked-session.png) - بعد التحقق من الأدلة، استخدم المشاكل لإعطاء الاستجابة مالكاً وتتبعها بشكل مستقل عن عمليات التدقيق المستقبلية. + بعد التحقق من الأدلة، استخدم المشاكل لإعطاء الاستجابة مالكاً وتتبعها بشكل مستقل عن جولات التدقيق المستقبلية. - ![صندوق وارد المشاكل يوضح العمل الفعال والمعترف به والمحلول مع الخطورة والملكية.](/images/dashboard/incidents.png) + ![صندوق الوارد للمشاكل يظهر العمل النشط والمقرّ والمحلول مع الخطورة والملكية.](/images/dashboard/incidents.png) - افتح المشكلة لتسجيل ملاحظات التحقيق وإخطار المشتركين والحفاظ على سجل الاستجابة. حلها فقط بعد نشر التصحيح والتحقق منه. + افتح المشكلة لتسجيل ملاحظات التحقيق وإخطار المشتركين والحفاظ على سجل الاستجابة. حلّها فقط بعد نشر المعالجة والتحقق منها. - ![عرض تفاصيل المشكلة مع مصدرها وأدلة الاختراق والمسؤولين والمشتركين والجدول الزمني والتعليقات.](/images/dashboard/incident-detail.png) + ![عرض تفاصيل المشكلة مع مصدرها وأدلة الانتهاك والمسؤولين والمشتركين والخط الزمني والتعليقات.](/images/dashboard/incident-detail.png) - + ```bash fp audits findings --audit checkout-reliability --status open fp audits finding fp audits ack --reason "owner assigned" fp audits assign --to engineer@example.com - fp audits mute --reason "expected in staging" --yes - fp audits dismiss --reason "false positive" --yes - fp audits resolve --yes - fp audits reopen - fp issues list --state firing + fp issues list fp issues show - fp issues ack fp issues assign --assignee engineer@example.com fp issues comment-add --body "policy is in observe mode" fp issues resolve --yes ``` - `mute` و `dismiss` و `resolve` تخفي أو تغلق نتيجة، لذا يتم تأكيد كل منها أولاً — مرر `--yes` في البرامج النصية. `ack` و `reopen` و `assign` قيود حجزي قابلة للعكس وتعمل فوراً. `ack` و `mute` و `dismiss` تأخذ `--reason`، وتستحق التمرير: يتم الاحتفاظ بها كملاحظات دائمة على النتيجة، وليس مكتوبة في سجل ومنسية. `resolve` و `reopen` و `assign` لا تأخذ سبباً. - - الإسناد يعمل بشكل مختلف على كل كائن. `fp audits assign` يتطلب `--to ` ويعيّن مالكاً واحداً؛ إعادة تشغيله تعيد الإسناد. `fp issues assign` يأخذ `--assignee` قابل للتكرار و**يستبدل** القائمة بأكملها، لذا حذفها يمسح كل مسؤول. - - استخدم `fp issues comment-list ` و `fp issues count --state firing` و `fp issues subscribe`/`unsubscribe`/`subscribers ` لبقية سطح المشكلة. + استخدم `fp issues subscribe ` و `fp issues unsubscribe ` و `fp issues subscribers ` لإدارة المراقبين. - اطّلع على [مرجع Cloud CLI للتدقيق والمشاكل](/ar/reference/cloud-cli#audits) لنتائج التدقيق و [`fp issues`](/ar/reference/cloud-cli#issues) لإدارة المشاكل. + انظر [مرجع Cloud CLI للتدقيق والمشاكل](/ar/reference/cloud-cli#audits) لنتائج التدقيق و [`fp issues`](/ar/reference/cloud-cli#issues) لإدارة المشاكل. ## مراجعة نتيجة -يقرر حقلان ما يجب فعله بها قبل أي شيء آخر. - -**`kind`** يفصل بين `failure` (حدث خطأ ما) و `policy` انتهاك (قاعدة تم كسرها) و `improvement` (يمكن أداء العمل بشكل أفضل). يتم عرضه كشارة على النتيجة. نتيجة `policy` هي التي يمكن لسياسة ما إغلاقها؛ الاثنان الآخران يحتاجان عادة إلى تغيير سير عمل أو تنبيه أو تدخل بشري. - -**`priority`** درجة من 0–1، تُحسب مرة أخرى لكل عملية، وهي الترتيب الذي يتم فيه فرز صف النتائج. تقسمها صفحة النتيجة تحت **لماذا تحتل هذا الترتيب**، كقيمة × وزن: - -| العامل | الوزن | -| --- | --- | -| التغطية | 0.30 | -| الخطورة | 0.25 | -| الحجم | 0.25 | -| حداثة العهد | 0.20 | - -ثم تأكد من أن النتيجة تحتوي على: +تأكد من أنها تحتوي على: -- نمط فشل ثابت، وليس فقط عنوان لحالة واحدة +- وضع فشل مستقر، وليس فقط عنوان لمرة واحدة - الخطورة والتأثير التشغيلي -- معرّفات الجلسات المتأثرة أو الاستعلامات الداعمة +- معرّفات الجلسة المتأثرة أو الاستعلامات الداعمة - سياق كافٍ لإعادة إنتاج السلوك - استجابة مقترحة تتطابق مع الأدلة -لإعادة إنتاج نتيجة، اسحبها بالكامل: `fp --json audits finding ` يُرجع السجل الكامل مع `evidence` و `evidence_queries` و `scope` دون تعديل، وهذا هو التحليل الذي تم تشغيله فعلاً. `--json` خيار عام، لذا يأتي قبل الأمر. - ## استخدم مشكلة لإدارة الاستجابة -أنشئ أو ربط مشكلة عندما تحتاج النتيجة إلى إسناد أو نقاش أو تغييرات حالة أو تعليقات أو مشتركين. يسجل `source` المشكلة مصدرها — `audit` أو `alert` أو `manual` — وهذا السبب في أن لوحة التحكم تعطي المشاكل عرضها الخاص **Issues** بدلاً من دمجها تحت تدقيق. - -الاشتراك جزئياً تلقائي. يتم الاشتراك للأشخاص عندما يعترفون بمشكلة أو يعلقون عليها أو يتم إسنادهم إليها أو يفتحونها — `fp issues subscribers` يسرد المشتركين النشطين فقط، لذا فهو ليس مجرد قائمة الاشتراكات اليدوية. يُرسل تعليق بريداً إلكترونياً لكل مشترك نشط، والتعليق يحتاج فقط إلى `issues:read`، لذا لن يكون المراجع القراءة فقط ملاحظاً صامتاً. +أنشئ أو ربط مشكلة عندما تحتاج النتيجة إلى إسناد أو نقاش أو تغييرات في الحالة أو تعليقات أو مشتركين. يمكن للمشاكل أن تمثل أيضاً حوادث التنبيهات والمشاكل المبلّغ عنها يدويّاً، وهذا هو السبب في أنها توجد تحت استجابة التدقيق وليس في الملاحة الأساسية. -حل المشكلة عندما يتم نشر التصحيح والتحقق منه. حل النتيجة عندما تتم معالجة نمط الفشل لمجموعة التدقيق. قد تختلف هذه اللحظات. +حل المشكلة عند نشر المعالجة والتحقق منها. حل النتيجة عندما يتم معالجة وضع الفشل لمجموعة التدقيق. قد تختلف هذه اللحظات. ## حوّل مشكلة إلى مسودة سياسة - - 1. افتح المشكلة وتحقق من نتيجتها والجلسات المذكورة والسبب الجذري والتوصية. - 2. حدد **generate policy** واستعرض نتيجة التأهل والنية الإنفاذية المقترحة. تعني نتيجة **no policy** أن السلوك قد يتطلب تنبيهاً أو تغيير سير عمل أو استجابة بشرية بدلاً من ذلك. - 3. حدد **write this policy**، ثم استعرض واختبر المصدر المُنتج في **Admin → policy editor** قبل تحديد **publish version**. استخدم **open the editor anyway** عندما تختلف مع فحص التأهل. - 4. انتقل إلى **Admin → enforcement**، ونشّر الإصدار في نمط **observe**، والتحقق من قراراته تحت **Observe → policy** قبل إنفاذه. + + 1. افتح المشكلة وتحقق من نتيجتها والجلسات المُستشهد بها والسبب الجذري والتوصية. + 2. حدد **إنشاء سياسة** وراجع نتيجة الأهلية والنية الفرض المقترحة. نتيجة **لا توجد سياسة** تعني أن السلوك قد يتطلب تنبيهاً أو تغييراً في سير العمل أو استجابة بشرية بدلاً من ذلك. + 3. حدد **اكتب هذه السياسة**، ثم راجع واختبر المصدر المُنشأ في **الإدارة → محرر السياسة** قبل تحديد **نشر الإصدار**. استخدم **افتح المحرر على أي حال** عندما تختلف مع فحص الأهلية. + 4. انتقل إلى **الإدارة → الفرض**، ونشّر الإصدار في وضع **مراقبة** والتحقق من قراراته تحت **مراقبة → السياسة** قبل فرضها. - يساعد عنوان المشكلة ووصف النتيجة والسبب الجذري والتوصية ونية التأهل في تأليف المسودة. لا يتم نشر أو نشر أي شيء تلقائياً. + عنوان المشكلة ووصف النتيجة والسبب الجذري والتوصية ونية الأهلية تساعد في تكوين المسودة. لا شيء يتم نشره أو نشره تلقائيّاً. - - استخدم CLI للفحص من الأدلة قبل فتح المشكلة في لوحة التحكم: + + استخدم واجهة سطر الأوامر للتحقق من الأدلة قبل فتح المشكلة في لوحة المعلومات: ```bash fp issues show - fp --json audits finding + fp audits finding fp events --session-id --full --all ``` - لوحة التحكم مسار واحد؛ CLI مسار آخر. `fp policies compose ""` تصيغ سياسة، `fp policies publish ./policy.mjs` تضرب إصدار (النشر لا ينشر أي شيء)، و `fp fleet deploy --add :observe` تضعها على جهاز في الظل. لاحقة `:observe` مطلوبة — `--add ` المجردة تنفذ فوراً. اقرأ ما كانت ستفعله مع `fp guardrails summary --since 24h`، ثم ارقَ مع `--add :enforce`. - - لمحاولة مصدر سياسة معادل على جهازك الخاص أولاً، وجّه CLI المحلي للملف: - - ```bash - failproofai policies -i -c ./checkout-policies.js - ``` - - ملف ينتهي اسمه بـ `policies.js` أو `policies.mjs` أو `policies.ts`، مُسقط في `.failproofai/policies/` في المشروع أو تحت `~/`، يتم تحميله عند كل حدث hook بدون أي أعلام على الإطلاق. + أهلية السياسة ونشر Cloud ونشر الأسطول هي سير عمل لوحة المعلومات. استخدم `failproofai policies --install --custom ` عندما تريد التحقق من صحة مصدر السياسة المعادل محليّاً أولاً. diff --git a/docs/ar/audits/local-audit.mdx b/docs/ar/audits/local-audit.mdx index ac23fac8d..882697fef 100644 --- a/docs/ar/audits/local-audit.mdx +++ b/docs/ar/audits/local-audit.mdx @@ -1,57 +1,74 @@ --- ---- title: "تدقيق سجل الوكيل المحلي" -description: "مسح سجل الوكيل على هذا الجهاز بحثاً عن سلوك محفوف بالمخاطر أو مهدر." +description: "امسح سجلات CLI للوكيل المدعومة دون الاتصال بالإنترنت وراجع السلوك المحفوف بالمخاطر أو الهدر محليًا." icon: "laptop-minimal-check" --- -يقرأ التدقيق المحلي سجل الوكيل الموجود بالفعل على هذا الجهاز ويفتح النتائج في `http://localhost:8020/audit`. لا يتطلب حساباً. +استخدم التدقيق المحلي لمراجعة فورية وخاصة قبل توصيل جهاز بـ Failproof AI Cloud. يقوم بمسح سجلات الوكيل المخزنة بالفعل على جهازك، وتشغيل نشاط الأداة من خلال السياسات المدمجة، وفتح لوحة نتائج محلية. -```bash -failproofai audit -``` +## تشغيل تدقيق تفاعلي -يغطي المسح السجل من جميع أجهزة التشغيل المدعومة التي يجدها. يعيد تشغيل كتالوج السياسات المدمج المكون من 39 سياسة في هذا الإصدار؛ لا يتم تضمين الحزم المثبتة والسياسات المخصصة. + + + يبدأ التدقيق المحلي من سطر الأوامر لأنه يجب أن يكتشف السجلات على الجهاز الحالي. قم بتشغيل `failproofai audit`؛ بعد المسح، يبدأ Failproof AI لوحة المعلومات المرفقة ويفتح **http://localhost:8020/audit**. -## قراءة النتيجة + في عرض التدقيق، راجع عدد الجلسات واستدعاءات الأداة والمشاريع والنتائج المتعلقة بالسياسة. ابدأ بالنتائج المتكررة، ثم افحص المشروع المتأثر وسجل الوكيل قبل تفعيل الإنفاذ. -ابدأ بالنتائج الأكثر تكراراً، ثم افتح الجلسة المتأثرة قبل تفعيل الفرض. + لوحة معلومات التدقيق المحلية منفصلة عن **Analyze → Audits** في Failproof AI Cloud. التدققيقات المحلية تبقى على الجهاز ولا تتطلب حسابًا أو اتصالاً بالشبكة. + + + ```bash + npm install -g failproofai + failproofai audit + ``` -ثلاثة حدود مهمة: + الأمر يجري مسحًا كاملاً لكل سجل مدعوم يجده. الأمر الحالي لا يقبل عوامل تصفية مثل `--since` أو `--cli` أو `--project` أو `--port` أو `--no-open`. -- يعيد التدقيق بناء أحداث الأدوات، وليس `Stop`، لذلك سياسات `require-*-before-stop` لا تظهر. -- ثمانية فحوصات "Audit-only" تحدد الأنماط المهدرة دون وجود سياسة مطابقة دقيقة. -- يتم تخطي `warn-repeated-tool-calls` لأن إعادة تشغيله ستعدّل الحالة على جانب النسخ. + اترك العملية قيد التشغيل أثناء استخدام لوحة المعلومات المحلية. اضغط على Ctrl+C عند الانتهاء. + + -للحصول على نتيجة قابلة للفرض، استخدم أمر السياسة الموضح في النتيجة. افحص [دعم فرض جهاز التشغيل](/ar/reference/harnesses#enforcement-capability) قبل الاعتماد عليه. +محولات التدقيق الحالية يمكنها قراءة السجلات من Claude Code و Codex و GitHub Copilot CLI و Cursor و OpenCode و Pi و Hermes و OpenClaw و Factory و Devin و Antigravity و Goose. يتم مسح السجلات المتاحة محليًا فقط. -تعيش النتيجة المخزنة مؤقتاً في `~/.failproofai/audit/dashboard.json` وتنتهي صلاحيتها بعد سبعة أيام. +## جدولة التدققيقات المحلية المتكررة -## جدولة المسح + + + افتح **Settings** في لوحة المعلومات المحلية، وفعّل التدققيقات المجدولة، واختر الفاصل الزمني، وعيّن عنوان البريد الإلكتروني الذي يجب أن يستقبل النتائج. تحدّث لوحة المعلومات وسطر الأوامر نفس إعدادات الجهاز. + + + فعّل تدقيقًا أسبوعيًا وأرسل النتائج إلى العنوان المحدد: -```bash -failproofai audit --schedule 7 -failproofai audit --status -failproofai audit --no-schedule -``` + ```bash + failproofai audit --schedule 7 --email reliability@example.com + failproofai audit --status + ``` -يقبل الفاصل الزمني 1–90 يوماً وافتراضياً 7. تتطلب الجدولة لأول مرة تسجيل دخول تفاعلي. يجب أن تكون خدمة الخلفية قيد التشغيل. + يقبل الفاصل الزمني 1-90 يومًا ويعود إلى 7 عند إغفاله. يوقع عليك الإعداد الأول عند الحاجة؛ يوفر `--email` عنوان التقرير دون طلب. -### ما يترك الجهاز + أوقف الجدول دون حذف سجل التدقيق المحلي: -لا يرسل التدقيق التفاعلي أي نتائج. قياس المسافة البادئة المجهول لواجهة سطر الأوامر مفعّل بشكل افتراضي؛ عطّله باستخدام `FAILPROOFAI_TELEMETRY_DISABLED=1`. + ```bash + failproofai audit --no-schedule + ``` + + -بعد اختيارك للجدولة، يرسل كل مسح مجدول معرّف الجهاز والتسمية والنظام الأساسي ونافذة المسح. إذا تم العثور على أنماط ضارة، فإنه يرسل أيضاً ملخصاً محدوداً يتضمن العدد والطوابع الزمنية وحتى ثلاثة أمثلة معدلة. لا ترسل المسحات النظيفة أي نتائج وبلا بريد إلكتروني. +يشغّل الخادم عمليات المسح المجدولة في الخلفية، وينعش النتيجة المخزنة مؤقتًا المستخدمة من قبل لوحة المعلومات المحلية، ويرسل التقرير المُعد. استخدم `failproofai audit` عندما تريد تشغيل مسح تفاعلي فورًا. - - نتائج التدقيق هي أدلة للمراجعة، وليست إثباتاً بأن كل إجراء مميز غير آمن. تحقق من الجلسة قبل تحويل النتيجة إلى فرض محظور. - +## الانتقال من الأدلة المحلية إلى عمليات Cloud + +التدقيق المحلي أساس سريع. وصّل الجهاز بـ Failproof AI Cloud عندما تحتاج إلى تتبعات مشتركة أو تدققيقات سكانية متكررة أو نتائج ومشاكل أو تنبيهات أو نشر السياسات على مستوى المنظمة أو صحة الأسطول. - - قم بتشغيل التدقيقات المشتركة المتكررة عبر الوكلاء والأجهزة. + + حدد هدفًا متكررًا وسكانًا ونافذة أدلة وقنوات الاستجابة. - - أضف السياسات المراجعة بعد تأكيد النتيجة. + + تحقق محليًا وانشر بشكل مقصود وأطلق النشر على مجموعة جهاز ضيقة أولاً. - \ No newline at end of file + + + + مخرجات التدقيق أدلة للمراجعة، وليست دليلاً على أن كل إجراء معلم غير آمن. أكد السياق قبل تحويل النتيجة إلى إنفاذ حجب. + \ No newline at end of file diff --git a/docs/ar/audits/overview.mdx b/docs/ar/audits/overview.mdx index 7dd9e5879..953324399 100644 --- a/docs/ar/audits/overview.mdx +++ b/docs/ar/audits/overview.mdx @@ -1,64 +1,56 @@ --- -title: "التدقيق" -description: "ابحث عن تشغيل الوكلاء للعثور على الإخفاقات المتكررة والسلوكيات المخاطرة والجهود المهدرة." +title: "التدقيقات" +description: "راجع مجموعة محددة من الجلسات للبحث عن الأخطاء التي لن تكشفها آثار البيانات وحدها." icon: "scan-search" --- -يقوم التدقيق بمراجعة عمليات تشغيل الوكيل العديدة مقابل هدف محدد ويعيد نتائج مدعومة بالأدلة. +يقوم التدقيق بالبحث في مجموعة مختارة من الجلسات عن هدف فشل محدد. يجمع بين أدلة التتبع ونتائج التقييم وضربات السياسة والسياق المرجعي لإنتاج نتائج يمكنك التصرف بناءً عليها.
-## محلي أو سحابي +انظر كيف ينتقل التدقيق من تشغيل مجدول إلى أخطاء مدعومة بأدلة يمكنك إصلاحها. -| | تدقيق محلي | تدقيق سحابي | -| --- | --- | --- | -| الأمر | `failproofai audit` | `fp audits` | -| القراءة من | سجل الوكيل على هذا الجهاز | الجلسات في منظمتك السحابية | -| ينتج | نتائج محلية على `localhost:8020/audit` | النتائج والمشاكل والتنبيهات المشتركة | -| يتطلب | لا يوجد حساب | اتصال سحابي ومفتاح API | +## فتح التدقيقات -استخدم التدقيق المحلي لمراجعة سريعة لجهاز واحد. استخدم السحابة عندما تحتاج فريق إلى تدقيق متكرر عبر الوكلاء والأجهزة. + + + انتقل إلى **تحليل → التدقيقات**. تعرض الصفحة حالة الجدولة والنتائج المفتوحة والتشغيل الأخير والتشغيل التالي والتكرار وما إذا كان للتدقيق صفحات ملخص أو مرجعية. حدد بطاقة للإعدادات وسجل التشغيل؛ حدد **تدقيق جديد** لإنشاء واحد. -## الأسئلة التي يمكن للتدقيق الإجابة عليها + ![صفحة التدقيقات تعرض التدقيقات المتكررة مع جدولها والحساسية وحالة التشغيل.](/images/dashboard/audits.png) + + + ```bash + fp audits list + fp audits list --enabled-only --show-id + fp audits show + fp audits findings --status open --limit 20 + ``` + + -- أين يتوقف الوكلاء دون التصعيد؟ -- أي أعطال الأدوات تؤدي إلى إعادة محاولات غير فعالة؟ -- هل يقوم الوكلاء بالوصول إلى البيانات خارج سير العمل المقصود؟ -- ما الذي تغير بعد تحديث النموذج أو الموجه أو الأداة؟ +استخدم التدقيق عندما تحتاج للإجابة على سؤال على مستوى المجموعة مثل: -## فتح تدقيقات السحابة +- أين يتخلى الوكلاء عن المهام دون تصعيد؟ +- أي أخطاء في الأدوات تؤدي إلى إعادة محاولات غير فعالة؟ +- هل يصل الوكلاء إلى البيانات خارج سير العمل المقصود؟ +- ما الذي تغير بعد إصدار نموذج أو موجه أو أداة؟ -انتقل إلى **Analyze → Audits**، أو استخدم: - -```bash -fp audits list -fp audits show -fp audits findings --status open --limit 20 -``` - -تستخدم أوامر التدقيق اسم التدقيق أو معرفه الكامل. تُستشهد بالنتائج من خلال معرفها الخاص. - -## من النتيجة إلى الوقاية +## تدفق استجابة التدقيق ```text Session → Audit → Finding → Issue → Policy - ↘ Alert + ↘ Alert for recurrence ``` -تشير النتيجة إلى الأدلة. تمتلك المشكلة الرد. تمنع السياسة نمط إجراء معروف؛ التنبيه يراقب تكرار الحدوث. - -لا يجب أن تصبح كل نتيجة سياسة. تصف نتيجة `policy` قاعدة قابلة للتطبيق. قد تحتاج `failure` أو `improvement` إلى سير عمل أو موجه أو نموذج أو تغيير أداة بدلاً من ذلك. +يجب أن تسمي النتيجة نمط الفشل وتشير إلى الأدلة. تملك المشكلة الإصلاح. تمنع السياسة نمط إجراء معروف؛ تكتشف التنبيهات التكرار عندما لا يكون الحد من الأضرار ممكناً أو يحتاج إلى مراقبة. - - - امسح السجل المحلي بدون حساب. - - - اختر الهدف والجلسات والجدول الزمني. + + + حدد الهدف والمجموعة والسياق المرجعي قبل التشغيل الأول. - - فرز الأدلة وتعيين رد. + + اذكر ما يجب على كل وكيل إنتاجه وما يجب ألا يفعله أبداً. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/ar/audits/recipes.mdx b/docs/ar/audits/recipes.mdx index e7603ca06..aba63e3e4 100644 --- a/docs/ar/audits/recipes.mdx +++ b/docs/ar/audits/recipes.mdx @@ -1,94 +1,54 @@ --- ---- title: "وصفات التدقيق" -description: "أهداف ابتدائية للتحقيقات الشائعة لحالات فشل الوكيل." +description: "أهداف البداية للتحقيقات الشائعة لأعطال الوكيل." icon: "book-open-check" --- -استخدم هذه كأهداف ابتدائية، ثم أضف وكيلك وبيئتك وسير العمل المتوقع. +استخدم هذه كأهداف بداية، ثم أضف وكيلك وبيئتك وسير العمل المتوقع. - انتقل إلى **Analyze → Audits → New audit**. سطر الوصفة من هذه الصفحة هو **الوصف** — ما تتوقع أن يكتشفه هذا التدقيق. قواعد سير العمل التي تجعل الهدف قابلاً للحكم عليه تذهب في **ملخصك**، في بطاقة **ما يعرفه**: خلفية يقرأها النموذج قبل أن ينظر إلى حدث واحد، محدود بـ 8,192 حرف، مضافة إلى ما يبحث عنه التدقيق بالفعل. الملخص ليس أبداً بديلاً للهدف وليس أبداً دليلاً على النتيجة. + انتقل إلى **Analyze → Audits → New audit**، انسخ إحدى الوصفات في الوصف أو الملخص، ثم أضف البيئة والوكيل والفترة الزمنية ورابط المراجع ذات الصلة. أنشئ التدقيق وتفحص التشغيل الأول قبل جدولته. - بعد ذلك حدد النطاق في **ما يقرأه**، لأن نصف هذه الوصفات هي ضوضاء بدونه. البيئات والوكلاء يضيقان المجموعة؛ **الأخطاء المراد تجاهلها** تسرد أنواع الأخطاء التي تتوقعها وتتعامل معها بالتصميم، لذا تتوقف عن حساب الفشل. يأخذ أسماء أنواع الأخطاء فقط، وهو ما يمنع وصفة حلقة إعادة المحاولة من الفيضان. + يحول نموذج التدقيق الجديد الوصفة إلى فحص فشل قابل للتنفيذ بإضافة النطاق والسياق والإيقاع والإخطارات. - يحول نموذج التدقيق الجديد الوصفة إلى فحص فشل قابل للتنفيذ بإضافة النطاق والسياق والتكرار والإخطارات. + ![نموذج التدقيق الجديد المكون بهدف مركز وجدول زمني ونطاق الوكيل والبيئة والسياق وقنوات الإخطار.](/images/dashboard/audit-new.png) - ![نموذج التدقيق الجديد المكون بهدف مركز، وجدول زمني، ونطاق الوكيل والبيئة، والسياق وقنوات الإخطار.](/images/dashboard/audit-new.png) + بعد الإنشاء، تأكد من ظهور التدقيق في القائمة بالحالة والجدول الزمني المتوقع قبل الاعتماد على التشغيلات المتكررة. - بعد الإنشاء، تأكد من ظهور التدقيق في القائمة بالحالة والجدول الزمني المتوقع قبل الاعتماد على الأشواط المتكررة. + ![صفحة التدقيقات حيث تظهر وصفة التدقيق الخاصة بسير العمل بعد الإنشاء.](/images/dashboard/audits.png) - افتح الشوط الأول وحسّن الوصفة إذا كانت نتائجها أوسع أو أضيق من وضع الفشل المقصود. + افتح التشغيل الأول وقم بتحسين الوصفة إذا كانت نتائجها أوسع أو أضيق من نمط الفشل المقصود. احفظ الوصفة كملف نصي وأرفقها أثناء الإنشاء: ```bash fp audits create retry-loop-review \ - --description "Find agents that repeat a failing tool call without changing anything" \ --scope '{"environments":["production"]}' \ - --ignore-error-type RateLimitRetried \ --text-file ./retry-loop-audit.txt \ --schedule-interval-secs 86400 ``` - - `--text` و`--text-file` هما طريقتان لإرسال نفس الملخص؛ مرّر واحد، وليس كليهما. أضف صفحات مرجعية باستخدام `--url`، حتى خمسة، `https://` عام فقط. أرسل كل شيء مع طلب الإنشاء: التدقيق الممكن الجديد يستحق فوراً، لذا قد يفتقد السياق المكتوب في استدعاء ثان الشوط الأول. -## احكم على الوصفة، وليس فقط على الصيغة - -يحرك إعدادان النتيجة أكثر من الصيغة. **الحساسية** (`low`، `medium`، `high`، الافتراضي `medium`) تحدد مدى رغبة الشوط في تحديد نمط؛ **النتائج لكل شوط** (`--top-k`، الافتراضي 50) يحد من عدد ما يحتفظ به. ارفع الحساسية لسؤال حيث يكلف الخطأ أكثر من الإيجابية الخاطئة، واخفضها لنمط الحجم الذي سيملأ الطابور بطريقة أخرى. كل وصفة أدناه تسمي نقطة انطلاق — غيرها بعد قراءة الشوط الأول، وليس قبله. - -التخلي عن المهمة والتصعيد البشري المفقود هما أحكام ضد ما كان يجب أن يفعله الوكيل، وليس ضد خطأ أثاره. اكتب أولاً [سياق الوكيل](/ar/audits/agent-contracts) لهذا الوكيل، أو لن يكون للتحليل معيار للحكم بناءً عليه. - - - ابحث عن جلسات حيث يكرر الوكيل استدعاء الأداة الفاشلة ذاتها بدون تغيير الإدخال، أو اختيار أداة بديلة، أو التصعيد إلى إنسان. - - ابدأ بـ `medium`، وأدرج أنواع الأخطاء التي تعيد محاولتها بهدف تحت **الأخطاء المراد تجاهلها**. + + ابحث عن الجلسات التي يكرر فيها الوكيل نفس استدعاء الأداة الفاشلة دون تغيير الإدخال أو اختيار أداة بديلة أو التصعيد إلى شخص ما. - - ابحث عن جلسات حيث الأداة المختارة لا تتطابق مع المهمة المذكورة، أو حيث إدخال الأداة ينتهك الشروط المسبقة المطلوبة لسير العمل. - - ابدأ بـ `medium`. ضع الشروط المسبقة نفسها في الملخص؛ بدونها ليس للتحليل قاعدة للتحقق منها. + + ابحث عن الجلسات التي لا تطابق فيها الأداة المختارة المهمة المذكورة، أو حيث يخالف إدخال الأداة الشروط المسبقة المطلوبة لسير العمل. - - ابحث عن جلسات تقرأ أو تكتب أو تنقل بيانات حساسة خارج المسارات والخدمات المعتمدة لهذا الوكيل. - - ابدأ بـ `high`. الخطأ المفقود يكلف أكثر من إيجابية خاطئة ترفضها مرة واحدة. + + ابحث عن الجلسات التي تقرأ أو تكتب أو تنقل بيانات حساسة خارج المسارات والخدمات المعتمدة لهذا الوكيل. - ابحث عن جلسات تنتهي بدون النتيجة المطلوبة، أو خطأ واضح، أو تسليم صريح إلى إنسان. - - ابدأ بـ `medium`، واكتب قسم **تمام عندما** للوكيل أولاً — هذه الوصفة هي حكم ضده. + ابحث عن الجلسات التي تنتهي بدون النتيجة المطلوبة أو خطأ واضح أو تسليم صريح لشخص ما. - - ابحث عن جلسات يتجاوز فيها النموذج أو الأداة أو المدة الإجمالية الميزانية المتوقعة، وحدد نمط الحدث المسؤول. - - ابدأ بـ `low` وارفعها إذا كان الشوط الأول رقيقاً. الميزانيات تنتمي للملخص، وأي نوع خطأ يثيره مسار بطيء بالتصميم ينتمي **للأخطاء المراد تجاهلها**. + + ابحث عن الجلسات التي تتجاوز فيها مدة النموذج أو الأداة أو الإجمالية الميزانية المتوقعة، وحدد نمط الحدث المسؤول. - - ابحث عن جلسات حيث الثقة، أو الفشل المتكرر، أو إرشادات السياسة تتطلب قرار بشري لكن الوكيل استمر بشكل مستقل. - - ابدأ بـ `high`، وحدد قاعدة التصعيد في قسم **يجب ألا** للوكيل لذا يصنف التحليل بناءً عليه. + + ابحث عن الجلسات التي تطلبت فيها الثقة أو الفشل المتكرر أو التوجيه السياساتي قرار بشري لكن الوكيل استمر بشكل مستقل. - - -## احصل على إجابة أولى قبل إنشاء أي شيء - -عدة من هذه الأنماط لديها بالفعل كواشف دون اتصال في التدقيق المحلي، الذي يقرأ سجلات الوكيل على آلتك الخاصة ولا يحتاج إلى حساب: - -| الكاشف | النمط الذي يحسبه | -| --- | --- | -| `sleep-polling-loop` | `sleep` طويلة، أو حلقة استقصاء `while … sleep … done` | -| `reread-after-edit` | قراءة ملف عدّله الوكيل للتو أو كتبه | -| `find-from-root` | `find` ضد `/` أو دليل عالي المستوى آخر | -| `redundant-cd-cwd` | `cd` في الدليل الذي يكون فيه الصدفة بالفعل | -| `prefer-edit-over-read-cat` | `cat`، `head`، `tail`، `less`، أو `more` على ملف مصدر واحد | -| `prefer-edit-over-sed-awk` | تحريرات موضعية عبر `sed -i` أو `awk … > file` | -| `prefer-write-over-heredoc` | محتوى متعدد الأسطر مكتوب عبر heredoc أو `echo > file` | -| `git-commit-no-verify` | `git commit --no-verify`، تخطي الخطاطيف | - -هذه الكواشف تحسب؛ لا تحجب، وليس أحدها يقيس التكلفة أو الكمون. شغّل `failproofai audit` لترى أي أنماط صدفة مسرفة وخطرة ينتجها وكلاؤك بالفعل قبل أن تدفع لتدقيق Cloud على نفس الأساس — انظر [التدقيق المحلي لسجل الوكيل](/ar/audits/local-audit). \ No newline at end of file + \ No newline at end of file diff --git a/docs/ar/audits/run.mdx b/docs/ar/audits/run.mdx index 8e55c2f56..bc0253a86 100644 --- a/docs/ar/audits/run.mdx +++ b/docs/ar/audits/run.mdx @@ -1,23 +1,24 @@ --- -title: "تشغيل ومراجعة التدقيق" -description: "قم بتشغيل التدقيق والتحقق من نطاق تغطيته وفحص النتائج الناتجة." +--- +title: "تشغيل المراجعة والتحقق منها" +description: "قم بتشغيل المراجعة والتحقق من نطاقها وفحص النتائج الناتجة." icon: "play" --- -قم بتشغيل التدقيق بعد أن يصبح الهدف والمجموعة المستهدفة محددة بدرجة كافية بحيث يعرف أي مشغل آخر كيف تبدو النتيجة الصحيحة. +قم بتشغيل المراجعة بعد أن تصبح أهدافها والمجموعة السكانية محددة بدرجة كافية بحيث يعرف مشغل آخر ما يبدو عليه الاكتشاف الصحيح. -## تشغيل وفحص التدقيق +## تشغيلها والتحقق منها - - 1. انتقل إلى **Analyze → Audits** وافتح التدقيق ثم حدد **run now**. تعني الرسالة المصفوفة أن المُرسِل سيبدأ التشغيل قريباً. - 2. افتح التشغيل الجديد لمراجعة حالته والنافذة ومدته وعدد النتائج والتقرير. + + 1. انتقل إلى **تحليل → المراجعات**، افتح المراجعة، وحدد **تشغيل الآن**. ستعني الاستجابة المصفوفة أن بواسطة الموزع سيبدأها قريباً. + 2. افتح التشغيل الجديد لمراجعة حالته والنافذة الزمنية والمدة وعدد النتائج والتقرير. 3. حدد جلسة الأدلة لفتح التتبع الدقيق. - 4. عُد إلى صفحة التدقيق لتعديل الإعدادات أو تعطيل الجدول أو فحص التشغيلات الأقدم. + 4. عد إلى صفحة المراجعة لتحرير الإعدادات أو تعطيل الجدول أو فحص التشغيلات القديمة. - ![صفحة تفاصيل التدقيق تعرض النتائج المفتوحة وحالة التشغيل الأخير والتالي ونافذة المسح والسياق والتحكم في تشغيل فوري والنتائج المصنفة.](/images/dashboard/audit-detail.png) + ![صفحة تفاصيل المراجعة مع النتائج المفتوحة وحالة آخر وتالي تشغيل ونافذة الكسح والسياق والتحكم بالتشغيل الآن والنتائج المرتبة.](/images/dashboard/audit-detail.png) - + ```bash fp audits run checkout-reliability fp audits runs checkout-reliability --limit 10 @@ -25,82 +26,41 @@ icon: "play" fp audits findings --audit checkout-reliability ``` - `fp audits run` يصف التدقيق في قائمة الانتظار؛ لا ينتظر اكتماله. تابعه بـ `fp audits runs ` واقرأ النتائج بعد انتهاء التشغيل. لا تعيد `--limit` أكثر من 50 تشغيل أخير مهما طلبت. - - يعمل الفرز على معرّف النتيجة وليس على التدقيق: - - ```bash - fp audits finding - fp audits ack --reason "owner assigned" - fp audits assign --to engineer@example.com - fp audits mute --reason "expected in staging" --yes - fp audits dismiss --reason "false positive" --yes - fp audits resolve --yes - fp audits reopen - ``` - - `mute` و `dismiss` و `resolve` تؤكد قبل التنفيذ، لذا مرّر `--yes` في السكريبتات. `ack` و `assign` و `reopen` تعمل فوراً. - - راجع مرجع [`fp audits`](/ar/reference/cloud-cli#audits) لأوامر سجل التشغيل والنتائج والفرز. + انظر إلى [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لسجل التشغيل والنتائج وأوامر التصنيف. -قد يتم رفض **run now**. التشغيل الذي يعمل بالفعل والتدقيق المعطّل كلاهما يرد `409`، مع السبب في حقل `error` في الاستجابة؛ التدقيق الذي لا يوجد أو التابع لمنظمة أخرى يرد `404`. - -| السبب | المعنى | الحل | -| --- | --- | --- | -| التدقيق غير معروف | التدقيق غير موجود أو يتبع منظمة أخرى. | أكد الاسم باستخدام `fp audits list`. | -| التدقيق معطّل | للتدقيق المعطّل لا توجد صفوف في قائمة الانتظار. التدقيق المتوقف مؤقتاً يعرض تحكماً في **run now**. | استأنفه أولاً أو استخدم `fp audits edit --enabled --yes`. | -| تشغيل قيد التنفيذ بالفعل | تشغيل واحد في كل مرة لكل تدقيق؛ يجب أن ينتهي التشغيل الحالي قبل وضع آخر في قائمة الانتظار. | تحقق منه باستخدام `fp audits runs `. | - ## قبل التشغيل - تأكد من وجود جلسات في نافذة الوقت المحددة. - تحقق من مرشحات البيئة والوكيل. -- تحقق من تحديث سياق المرجع. كل تشغيل يعيد قراءة صفحات التدقيق ويعود إلى النسخة المخزنة عندما لا يتمكن من الوصول إلى إحداها، لذا تستمر الصفحة المنقولة أو المحذوفة في تقديم نص قديم حتى تصلح عنوان URL. -- تأكد من أن الهدف يصف نمط فشل وليس استنتاجاً مرغوباً. +- تحقق من أن السياق المرجعي حالي. +- تأكد من أن الهدف يصف نمط فشل وليس استنتاج مطلوب. ## مراجعة التشغيل -تفتح صفحة تفاصيل التدقيق بخمس بطاقات: **النتائج المفتوحة** في انتظار الفرز و **آخر تشغيل** و **التشغيل التالي** و **النافذة** (إلى متى يعود كل تشغيل) و **الحساسية** (مدى سرعة الفحص عن النمط: `low` أو `medium` أو `high`). حد النتائج على الأكثر N في التشغيل هو إعداد منفصل، نتائج لكل تشغيل (`--top-k`، الافتراضي 50). تجيب هذه الخمس على سؤال التغطية بسرعة أكبر من فتح التشغيل. - -ثم افحص شدة كل نتيجة ووصفها وجلسات الأدلة والاستعلامات الداعمة ومسار الوقاية المقترح. يتم ترتيب النتائج بنقاط **الأولوية** بين 0 و 1، ومصنفة لكل تشغيل، وكل نتيجة تعرض العوامل الأربعة الموزونة: - -| عامل التصنيف | الوزن | -| --- | --- | -| التغطية | 0.30 | -| الحجم | 0.25 | -| الشدة | 0.25 | -| الحداثة | 0.20 | +ابدأ بحالة التشغيل وتغطية الجلسة وما إذا كان تحليل النموذج قد تم تشغيله. ثم افحص شدة كل نتيجة ووصفها وجلسات الأدلة والاستعلامات الداعمة والمسار الموصى به للوقاية. -النتيجة في إحدى الحالات الخمس بالضبط: `open` أو `recurring` أو `resolved` أو `dismissed` أو `muted`. استعلام `findings` بدون تصفية الحالة يعيد المجموعة المباشرة — `open` بالإضافة إلى `recurring`. النتيجة التي تكتمها أو تغضّ الطرف عنها أو تحلّها تترك تلك المجموعة؛ `ack` و `assign` لا يغيران الحالة، لذا تبقى النتيجة في قائمة الانتظار — مخفضة الأولوية أو مملوكة وليست محذوفة. اطلب حالة صراحة لترى الحالات التي غادرت. - -استخدم حالة النتيجة للإقرار أو الكتم أو الغض أو الحل أو إعادة الفتح أو تعيين العمل. احتفظ بالأدلة حتى عندما يتم غض الطرف عن النتيجة؛ فهي تشرح السبب. يغطي [النتائج والمشاكل](/ar/audits/findings-and-issues) ما يفعله كل فعل بالتشغيلات المستقبلية. +استخدم حالة النتيجة للإقرار أو الكتم أو الرفض أو الحل أو إعادة الفتح أو تعيين العمل. احفظ الأدلة حتى عند رفض النتيجة؛ فهي توضح سبب اتخاذ القرار. ## تفسير التشغيل الفارغ أو المتأخر -| حالة التشغيل | المعنى | الحل | +| حالة التشغيل | ما تعنيه | ما يجب فعله | | --- | --- | --- | -| انتهى التحليل وأسفر عن صفر نتيجة | الأدلة المحددة لم تدعم النتيجة عند حساسية التكوين. | تأكد من أن النطاق يحتوي على جلسات تمثيلية، ثم اعتبر النتيجة صحيحة ما لم يكن الهدف أو السياق غامضاً جداً. | -| تم تخطي تحليل النموذج أو فشل | التشغيل ينتهي بصفر نتيجة لكنه لم يجرِ التحقيق المستند إلى الوكيل. المسح الحتمي بدون بيانات اعتماد وPII لا يزال يبلغ عن تطابقات في إحصائيات التشغيل لكنه لا ينشئ نتائج. | أصلح خدمة التحليل أو التكوين وأعد التشغيل. لا تفسّر النتيجة الفارغة على أنها دليل على أن المجموعة صحيحة. | -| تحليل النموذج معطّل | التشغيل ينجح بصفر نتيجة. المسح الحتمي لا يحل محل تحليل النموذج ولا ينفتح على نتائج. | فعّل تحليل النموذج أو عطّل التدقيق بدلاً من الاعتماد على تدقيق لا يستطيع إنتاج نتائج. | -| لا توجد سعة تحليل متاحة فوراً | التدقيق يبقى في قائمة الانتظار ويعيد المحاولة بدلاً من تخطي المجموعة. | انتظر السعة أو انشر نقاط تثبيت التدقيق. يجب على مشغلي الخوادم المحلية توسيع نسخ الوكيل وسعة المُرسِل المطابقة. | -| تبقى السعة غير متاحة لنافذة إعادة المحاولة | التشغيل يستسلم بصفر نتيجة ويرسل إشعار فشل عند توفر تسليم البريد الإلكتروني. | تحقق مما إذا كان أسطول التدقيق مشبعاً أو يعيد التشغيل بشكل متكرر. | - -الصفوف الثلاث الأخيرة تصف سلوك خادم Cloud API وموزّعه. على Cloud المُدار هذا من مسؤولية Failproof AI؛ على نشر محلي الخوادم فهو من مسؤوليتك. - -عندما لا يعمل التحليل، تحافظ عمليات التدقيق `since_last` على النافذة غير المحللة مفتوحة للتشغيل الناجح التالي. لا يتم سحب النتائج الموجودة لأن التحليل المتخطى ليس دليلاً على اختفاء الفشل. - -## فهم الإشعارات +| تم تشغيل التحليل وأنتج صفر نتائج | الأدلة المختارة لم تدعم نتيجة في الحساسية المكونة. | تأكد من أن النطاق يحتوي على جلسات تمثيلية، ثم اعتبر النتيجة سليمة ما لم يكن الهدف أو السياق غير واضح جداً. | +| تم تخطي تحليل النموذج أو فشل | يكتمل التشغيل بصفر نتائج، لكنه لم يقم بالتحقيق الوكيل. المسح الحتمي للبيانات الاعتماد والمعلومات الشخصية لا يزال يبلغ عن عدد التطابقات في إحصائيات التشغيل ولكنه لا ينشئ نتائج. | أصلح خدمة التحليل أو الإعدادات وأعد التشغيل. لا تفسر النتيجة الفارغة كدليل على أن المجموعة السكانية سليمة. | +| تحليل النموذج معطل | يكتمل التشغيل بنجاح مع صفر نتائج. المسح الحتمي لا يحل محل تحليل النموذج ولا يفتح نتائج. | فعّل تحليل النموذج أو عطّل المراجعة بدلاً من الاعتماد على مراجعة لا يمكنها إنتاج نتائج. | +| لا توجد سعة تحليل متاحة فوراً | تبقى المراجعة في طابور الانتظار وتعيد المحاولة بدلاً من تخطي المجموعة السكانية. | انتظر السعة أو وزع نقاط اثبات المراجعة. يجب على المشغلين ذاتي الاستضافة توسيع نطاق نسخ وكيل المراجعة والسعة المطابقة للموزع. | +| السعة تبقى غير متاحة لنافذة إعادة المحاولة | يستسلم التشغيل مع صفر نتائج ويرسل إخطار فشل عند توفر تسليم البريد الإلكتروني. | تحقق مما إذا كانت أسطول المراجعة مشبعاً أو يعيد تشغيله بشكل متكرر. | -التشغيل الناجح يبلغ فقط عندما يجد شيئاً **جديداً**. الصمت من تدقيق صحي هو الحالة الطبيعية وليس علامة على أن لا شيء عمل — تحقق من **آخر تشغيل** على صفحة التدقيق أو استخدم `fp audits runs ` لترى أنه عمل. التدقيق الذي لا توجد قنوات مختارة له يحفظ النتائج ولا يبلغ أحداً. +عندما لا يتم تشغيل التحليل، تحافظ مراجعات `since_last` على تلك النافذة غير المحللة مفتوحة للتشغيل الناجح التالي. لا يتم إزالة النتائج الموجودة لأن التحليل المتخطى ليس دليلاً على اختفاء الفشل. -التشغيل الفاشل أو خطوة تحليل النموذج الفاشلة تستخدم متلقي البريد الإلكتروني للتدقيق. إذا لم يكن للتدقيق قناة بريد إلكتروني، يعود Failproof AI إلى إعداد `alerts.email_default_recipients` للمنظمة لذا حتى التدقيق المعطّل بصمت له مسار تصعيد. +## فهم إخطارات الفشل -يجب تفعيل البريد الإلكتروني للمنظمة وتكوين SMTP. وإلا فسيتم تسجيل الخطأ لكن لا يمكن تسليم أي بريد إلكتروني. فشل التشغيل لا يحرك رابط الجدول الثابت للتدقيق. +يستخدم التشغيل الفاشل أو خطوة تحليل النموذج الفاشلة مستقبلي البريد الإلكتروني للمراجعة. إذا لم تكن للمراجعة قناة بريد إلكتروني، فإن Failproof AI ترجع إلى إعداد `alerts.email_default_recipients` للمنظمة بحيث تظل المراجعة المكسورة بصمت لديها مسار تصعيد. يجب تمكين البريد الإلكتروني للمنظمة وتكوين SMTP. وإلا فسيتم تسجيل الفشل ولكن لا يمكن إرسال بريد إلكتروني. فشل التشغيل لا يحرك نقطة الجدول الثابتة للمراجعة. -كل تشغيل أيضاً يحفظ [السياق الدقيق للوكيل](/ar/audits/agent-contracts) المستخدم لكل وكيل كلقطة عقد. التعديلات اللاحقة لا تغير معيار الأدلة المسجل مع التشغيل الأقدم. +كل تشغيل يخزن أيضاً السياق الدقيق [للوكيل](/ar/audits/agent-contracts) المستخدم لكل وكيل كلقطة عقد. لا تغير التعديلات اللاحقة معيار الأدلة المسجل مع تشغيل سابق. - لا تنشر سياسة حجب مباشرة من نتيجة غير تم التحقق منها. افتح الآثار المذكورة وتأكد من أن القاعدة تفصل بين السلوك غير الآمن والعمل المشروع. + لا تقم بنشر سياسة حجب مباشرة من نتيجة غير مؤكدة. افتح الآثار المذكورة وتأكد من أن القاعدة تفصل السلوك غير الآمن عن العمل المشروع. \ No newline at end of file diff --git a/docs/ar/audits/setup.mdx b/docs/ar/audits/setup.mdx index e274e1ffb..ef014effa 100644 --- a/docs/ar/audits/setup.mdx +++ b/docs/ar/audits/setup.mdx @@ -1,26 +1,24 @@ --- +--- title: "إعداد تدقيق" -description: "تحديد هدف التدقيق وملء الجلسة وسياق الأدلة." +description: "تحديد هدف التدقيق، وملء الجلسة، وسياق الأدلة." icon: "sliders-horizontal" --- -تبدأ جودة التدقيق من نطاقه. طلب عام مثل "ابحث عن المشاكل" ينتج نتائج أقل فائدة من سؤال فشل محدد وملموس. +تبدأ جودة التدقيق من نطاقه. الطلب الواسع مثل "ابحث عن المشاكل" ينتج نتائج أقل فائدة من سؤال فشل محدد. ## تكوين التدقيق - 1. انتقل إلى **Analyze → Audits → New audit** وأدخل الاسم والوصف. الاسم فريد لكل منظمة؛ الوصف يسجل ما تتوقع أن يكتشفه هذا التدقيق. - 2. في **when it runs**، حدد التكرار والنافذة الزمنية. في **what it reads**، ضيّق السكان باستخدام البيئات والوكلاء وأنواع الأخطاء المراد تجاهلها — حقل فارغ يتضمن كل شيء. في **how it judges**، حدد الحساسية وعدد النتائج لكل تشغيل. - 3. في **what it knows**، اكتب موجز المشغل وأضف الصفحات التي يقرأها التدقيق. الموجز هو خلفية يقرأها النموذج قبل فحص أي حدث واحد: يُضاف إلى ما يبحث عنه هذا التدقيق بالفعل، وليس أبداً بديلاً، وليس أبداً دليلاً على نتيجة. - 4. افتح درج **agents** لإضافة أو مراجعة سياق كل وكيل. يحفظ بشكل مستقل عن التدقيق، والرأس الخاص به يحسب عدد وكلائك الذين لديهم واحد بالفعل. انظر [agent context](/ar/audits/agent-contracts). - 5. اختر قنوات الإشعارات واختر **create audit**. يبدأ التدقيق الجديد مفعّلاً، وتم جدولة التشغيل الأول له فوراً. - - ![نموذج التدقيق الجديد يحتوي على الاسم والوصف والتكرار والنافذة الزمنية ونطاق البيئة والوكيل والأخطاء المتجاهلة وإعدادات التحليل والموجز والصفحات المرجعية وقنوات الإشعارات.](/images/dashboard/audit-new.png) + 1. انتقل إلى **تحليل → التدقيقات → تدقيق جديد** وأدخل الاسم والوصف. + 2. عيّن التكرار، نافذة الوقت، نطاق الوكيل/البيئة، الأخطاء المتجاهلة، الحساسية، والحد الأقصى للنتائج. + 3. في **الوكلاء**، أضف أو راجع سياق الوكيل، ثم أضف إيجاز المشغل وأي عناوين URL مرجعية HTTPS عامة. + 4. اختر قنوات الإشعارات وحدد **إنشاء تدقيق**. يتم إدراج التشغيل الأول على الفور. - **agents** في بطاقة **what it reads** هو مرشح نطاق — يحدد الجلسات التي يمسحها كل تشغيل. ما يقوم به الوكيل *من أجله* يعيش في درج الوكلاء المنفصل. + ![نموذج التدقيق الجديد يحتوي على الاسم والوصف والتكرار والنافذة ونطاق البيئة والوكيل والأخطاء المتجاهلة وإعدادات التحليل والإيجاز وصفحات المرجع وقنوات الإشعارات.](/images/dashboard/audit-new.png) - + ```bash fp audits create checkout-reliability \ --description "Find checkout failures that agents do not recover from" \ @@ -32,44 +30,16 @@ icon: "sliders-horizontal" --url https://runbooks.example.com/checkout ``` - لكل حقل ما عدا الاسم قيمة افتراضية على الخادم، لذا `fp audits create nightly` البسيط هو بالفعل تدقيق يومي صحيح. يتم رفض الاسم المأخوذ مقدماً، قبل إنشاء أي شيء. تبدأ التدقيقات الجديدة مفعّلة إلا إذا مررت `--disabled`، ويتم جدولة التشغيل الأول للتدقيق المفعّل فوراً. - - استند إلى تعريف مُحفوظ باستخدام JSON مع `--file audit.json` وطبّق الأعلام فوقه. هذا هو المسار القابل للتكرار عندما تتم مراجعة تعريفات التدقيق أو الاحتفاظ بها في التحكم في الإصدار. + يتم إدراج التشغيل الأول على الفور. أدرج الإيجاز وعناوين URL المرجعية أثناء الإنشاء بحيث يتلقاها التشغيل. انظر المرجع الكامل [`fp audits create`](/ar/reference/cloud-cli#audits). -## النطاقات والقيم الافتراضية - -تتم التحقق من صحة الإعدادات الرقمية على كلا الجانبين، لذا تكون القيمة خارج النطاق خطأ استخدام وليس طلب مرفوض. - -| الإعداد | علم CLI | القيم المقبولة | القيمة الافتراضية | -| --- | --- | --- | --- | -| التكرار | `--schedule-interval-secs` | 3600–604800 (ساعة واحدة إلى 7 أيام) | 86400 (يومي) | -| نقطة ربط الجدولة | `--schedule-anchor` | ISO 8601 UTC؛ يتم رفض نقطة ربط أبعد من 365 يوماً | الساعة 09:00 UTC التالية | -| النافذة الزمنية | `--window-mode` | `fixed`, `since_last` | `since_last` | -| النظر للخلف | `--lookback-window-secs` | 3600–7776000 (ساعة واحدة إلى 90 يوماً) | 604800 (7 أيام) | -| الحساسية | `--sensitivity` | `low`, `medium`, `high` | `medium` | -| النتائج لكل تشغيل | `--top-k` | 1 أو أكثر | 50 | - -تحدد نقطة الربط مرحلة الجدولة: تهبط التشغيلات على `anchor + N * interval`، لذا لا يمكن للتشغيل البطيء أو **run now** اليدوي أن يجرف التكرار. يتم جدولة التشغيل الأول فوراً عند الإنشاء بغض النظر عن نقطة الربط. - -## الموجز والصفحات المرجعية - -يُظهر النموذج كلا الحدين كعدادات، والـ CLI يفرض نفس الحدين: - -- الموجز محدود بـ 8192 حرفاً (`--text`، أو `--text-file` لقراءته من ملف — مرّر أحدهما أو الآخر، وليس كليهما). -- يشير التدقيق إلى خمس صفحات على الأكثر، عام `https://` فقط (`--url`، مكرر). - -تتم التحقق من صحة عناوين URL المرجعية أثناء الحفظ. يتم رفض العناوين الخاصة والحلقية وعناوين بيانات السحابة، ويفشل عنوان URL المرفوض الإنشاء بالكامل — لم يتم ترك تدقيق نصف مصنوع. يتم جلب الصفحات المقبولة في الخلفية، لذا لن يوقف الموقع البطيء الحفظ. يعيد كل تشغيل قراءتها ويعود إلى اللقطة المخزنة عندما لا يمكن الوصول إلى واحدة، واللقطات تنعش بمفردها كل أسبوع. استخدم `fp audits context-refresh ` عندما تعرف أن صفحة تغيرت وتريد التقاطها قبل التشغيل التالي. - -أرسل الموجز والعناوين مع طلب الإنشاء بدلاً من مكالمة ثانية. يستحق التدقيق الجديد المفعّل في اللحظة التي يتعهد بها صفه، لذا يمكن للسياق المكتوب لاحقاً أن يتفوق عليه المرسل ويفوت التشغيل الأول — التشغيل الذي تراقبه. غيّره لاحقاً مع `fp audits context-set `، الذي يستبدل أيهما تسميه ويترك الآخر وحده. - - ابدأ بجلسة فاشلة معروفة وعدة جلسات عادية. هذا يعطي التدقيق مثالاً إيجابياً ومجموعة مقارنة. + ابدأ بجلسة فاشلة معروفة وعدة جلسات عادية. وهذا يعطي التدقيق مثالاً إيجابياً ومجموعة مقارنة. - يتم تخزين سياق التدقيق كمورد خاص به. نقطة نهاية التعريف ترفض كتابته عند التحديث، لذا لن يؤدي تحرير عادي غير مرتبط للتدقيق إلى الكتابة فوق الموجز أو الصفحات المرجعية. + يتم تخزين سياق التدقيق كمورد منفصل بحيث لا يؤدي تحرير التدقيق إلى إزالة المادة المرجعية بشكل عرضي. \ No newline at end of file diff --git a/docs/ar/index.mdx b/docs/ar/index.mdx index 74af08b02..0a82a52cb 100644 --- a/docs/ar/index.mdx +++ b/docs/ar/index.mdx @@ -1,58 +1,40 @@ --- -title: "اجعل وكيلك failproof" -description: "شاهد ما يفعله وكلاؤك، وجد الأخطاء، ووقفها من الحدوث مرة أخرى." +--- +title: "اجعل وكيلك آمنًا تماماً" +description: "قابلية الملاحظة والتطبيق لكل بيئة تشغيل يعمل فيها وكيلك — واجهات سطر الأوامر للترميز، بوابات الدردشة، المساعدات المستضافة ذاتياً، والوكلاء المزودين بأدوات المراقبة الخاصة بك." icon: "shield-check" --- -Failproof AI يساعد أي شخص يقوم بتشغيل الوكلاء على فهم ما حدث، والعثور على الأخطاء، ومنع تكرارها. - -يعمل مع 12 بيئة وكيل شائعة، بما في ذلك Claude Code و Codex و Hermes و OpenClaw و Goose. يمكن للوكلاء المبنيين باستخدام LangChain أو CrewAI أو LlamaIndex أو Pydantic AI أو وقتك الخاص الإبلاغ من خلال [Python SDK](/ar/reference/custom-agents). - - - - ثبّت Failproof AI، وصل وكلاءك، واختر ما تريد فرضه. - - - ابحث عن الجلسات، وحقق في الأخطاء، وابنِ لوحات معلومات باللغة الطبيعية. - - - -## ابدأ محليًا أو اتصل بـ Cloud +Failproof AI يساعد الفرق على فهم ما فعله الوكلاء، والعثور على أماكن فشلهم، ونشر الحماية قبل حدوث نفس السلوك مرة أخرى. - - افتح لوحة المعلومات على `localhost:8020` وقم بتشغيل `failproofai audit`. يبقى سجل وكيلك على هذه الآلة. + + استخدم المهارة لأتمتة مشروعك وتوصيله والتحقق من وصول سجلات الوكيل. - - شاهد الجلسات عبر الآلات وأدر السياسات لفريقك. + + حلل واستعلم وقم ببناء لوحات معلومات وتشغيل عمليات التدقيق باللغة الطبيعية على سجلات وكيلك. -يختار الإعداد عن قصد عدم وجود حزمة سياسة. أضف حزمتنا بعد الإعداد: - -```bash -failproofai policies add FailproofAI/policies -``` - -حتى ذلك الحين، فقط `block-failproofai-commands` يعمل. إنه يوقف الوكيل من تعطيل Failproof AI. - -## ما الذي يمكنك فعله - - - تابع تشغيل الوكيل من خلال استدعاءات النموذج والأدوات والأخطاء وقرارات السياسة. + + تابع استدعاءات النموذج والأدوات والأخطاء والمدخلات البشرية والكمون وقرارات السياسة في جلسة واحدة. - - راجع الأدلة عبر تشغيل واحد أو أكثر. + + قم بتدقيق مجموعة محددة من الجلسات وراجع النتائج المدعومة بالأدلة وتابع الإصلاح كمشاكل. - لاحظ حماية على النشاط الفعلي، ثم فرضها عندما تكون جاهزًا. + حول وضع فشل معروف إلى سياسة وراقب تأثيره ونشره عبر أسطولك. -> **Session → Audit → Finding → Issue → Policy** -> شاهد ما حدث، وجد الخطأ، وتحمل المسؤولية عن الرد، ثم منعه. +> **جلسة → تدقيق → نتيجة → مشكلة → سياسة**
+> تتبع ما حدث، أوجد الفشل، أدر الاستجابة، ثم منع نفس السلوك في التشغيلات المستقبلية. + +## ابدأ من هنا + +إذا كنت تنشر وكيلك المزود بأدوات المراقبة للمرة الأولى، فابدأ بـ [البدء السريع](/ar/start/quickstart). إذا كانت البيانات تصل بالفعل، فافتح [الجلسات](/ar/sessions/overview) وتفحص تشغيلاً حقيقياً قبل تكوين عمليات التدقيق أو السياسات. - - الإعداد يدعم Linux و macOS. راجع [harnesses المدعومة](/ar/reference/harnesses) لمعرفة ما يمكن لكل بيئة وكيل مراقبته أو حظره. - \ No newline at end of file + + أكمل سير العمل من الطرف إلى الطرف الآخر من المراقبة إلى سياسة آمنة ومنشورة. + \ No newline at end of file diff --git a/docs/ar/policies/builtin-catalog.mdx b/docs/ar/policies/builtin-catalog.mdx index 9ca7c095e..afda0631f 100644 --- a/docs/ar/policies/builtin-catalog.mdx +++ b/docs/ar/policies/builtin-catalog.mdx @@ -1,147 +1,106 @@ --- ---- title: "كتالوج السياسات المدمجة" -description: "استعرض كل سياسة من سياسات Failproof AI المدمجة، مع محفزاتها وحالتها الافتراضية والمعاملات القابلة للتكوين." +description: "اطّلع على كل سياسة مدمجة من سياسات Failproof AI، وحافزها، والحالة الموصى بها، والمعاملات القابلة للتكوين." icon: "list-checks" --- -يتم تسليم 38 من أصل 39 سياسة مدمجة كحزمة `FailproofAI/policies`؛ يتم شحن `block-failproofai-commands` مجمعة في الحزمة لأن الحزمة قد لا تعلن `alwaysOn`. الحزمة المثبتة هي مصدر الحقيقة لما يمكن لهذا الجهاز أن يفرضه: - -```bash -failproofai policies show FailproofAI/policies # the catalog, as published -failproofai policies # what is enabled here -``` - -يسرد `failproofai policies` الملفات المخصصة وملفات الاتفاقيات والحزم المثبتة والتعيينات السحابية. لا يحتوي على قسم مدمج، لذا لا يمكنه الإجابة على "أي من السياسات المدمجة موجود" — `policies show` و[Policy Hub](https://befailproof.ai/policy-hub/FailproofAI/policies/) هما المكانان اللذان يتم الإجابة عليهما هناك. +الحزمة المثبتة هي مصدر الحقيقة لتوفر السياسات. قم بتشغيل `failproofai policies` بعد كل تحديث لأن إدخالات الكتالوج والسلوك قد يتغيران مع إصدار الحزمة. -## القيم الافتراضية وكيفية الاختيار +## خط الأساس الموصى به -يقوم `failproofai policies add FailproofAI/policies` بتفعيل القيم الافتراضية للحزمة — الصفوف الـ 10 المشار إليها بـ **on** أدناه. يتم تفعيل `block-failproofai-commands` بغض النظر وليست جزءًا من هذا التحديد. يأخذ `--all` كل شيء؛ `--category ` و`--policy ` يأخذان جزءًا. الاختصار بجانب كل عنوان هو ما يطابقه `--category`: +يعمل الإعداد الموجه حالياً على تفعيل معقمات الأسرار، وحماية البيئة، الحماية الذاتية، حراس الأوامر الكارثية، وسلامة الفروع المحمية: -```bash -failproofai policies add FailproofAI/policies --category git,database +```text +sanitize-jwt sanitize-api-keys +sanitize-connection-strings sanitize-private-key-content +sanitize-bearer-tokens protect-env-vars +block-env-files block-secrets-write +block-failproofai-commands block-sudo +block-curl-pipe-sh block-rm-rf +block-push-master block-force-push ``` -`block-failproofai-commands` **مفعل دائمًا**. يسجل نفسه في كل تقييم سواء ظهر في اختيارك أم لا، ولا يمكن تعطيله أو إيقافه مؤقتًا — الحماية ضد تعطيل الوكيل للفرض الذي يمكن للوكيل تعطيله ليست حماية. قد لا تعلن الحزمة عن `alwaysOn`، وهذا هو السبب في شحن هذه السياسة الواحدة مجمعة في الحزمة بدلاً من أن تكون في الحزمة. - -## التعقيم — `sanitize` - -تعمل هذه على `PostToolUse`، بعد تنفيذ الأداة بالفعل. **تكتشف وترفض نتيجة الأداة**؛ لا تحرر كلمة فرعية وتعيد الباقي. - -الرفض هنا يصل إلى النموذج فقط على الأطر التي تستهلك حكم `PostToolUse` — **codex** و **copilot**، حيث يحل السبب محل نتيجة الأداة بالكامل. على claude و cursor و opencode و pi و hermes و openclaw و factory و devin و antigravity و goose، يكون `PostToolUse` مراقبة فقط: يتم تسجيل الكشف ولا تزال الإخراج يصل إلى النموذج. - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `sanitize-jwt` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على JWT. | -| `sanitize-api-keys` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على مفتاح OpenAI أو Anthropic أو GitHub أو AWS أو Stripe أو Google. | -| `sanitize-connection-strings` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على سلسلة اتصال قاعدة بيانات بها بيانات اعتماد مضمنة. | -| `sanitize-private-key-content` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على محتوى مفتاح خاص بصيغة PEM. | -| `sanitize-bearer-tokens` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على رمز `Authorization: Bearer`. | - -## البيئة — `environment` - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `protect-env-vars` | `PreToolUse` على `Bash` | on | منع الأوامر التي تقرأ متغيرات البيئة. | -| `block-env-files` | `PreToolUse` | on | منع القراءة والكتابة لملفات `.env`. | -| `block-read-outside-cwd` | `PreToolUse` على `Read`، `Glob`، `Grep`، `Bash` | off | حافظ على قراءات الملفات داخل دليل العمل للجلسة. | - -## الأوامر الخطرة — `dangerous-commands` - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `block-sudo` | `PreToolUse`، `PermissionRequest` على `Bash` | on | منع `sudo` ما لم يطابق نمط السماح. | -| `block-curl-pipe-sh` | `PreToolUse` على `Bash` | on | منع النصوص المحملة الموجهة مباشرة إلى shell. | -| `block-failproofai-commands` | `PreToolUse`، `PermissionRequest` على `Bash`، `Write`، `Edit`، `NotebookEdit` | **always on** | منع كل استدعاء CLI من Failproof AI، الإيقاف الذاتي وإلغاء التثبيت. | -| `block-rm-rf` | `PreToolUse` على `Bash` | off | منع أنماط الحذف العودي الكارثية. | -| `block-secrets-write` | `PreToolUse` على `Write` | off | منع الكتابة لأسماء ملفات المفاتيح السرية والبيانات الاعتمادية الشائعة. | - -## أوامر البنية التحتية — `infra-commands` - -السبعة كلهم معطلة بشكل افتراضي: فهي تبوب الأدوات التي يستخدمها العمل الشرعي بشكل مستمر، لذا فهي تنتمي إلى المستودعات والآلات التي تحتاج إليها. - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `block-kubectl` | `PreToolUse` على `Bash` | off | ابوب طفرات `kubectl` في الكتلة. | -| `block-terraform` | `PreToolUse` على `Bash` | off | ابوب أوامر `terraform` و`tofu`. | -| `block-aws-cli` | `PreToolUse` على `Bash` | off | ابوب أوامر CLI `aws`. | -| `block-gcloud` | `PreToolUse` على `Bash` | off | ابوب أوامر `gcloud`. | -| `block-az-cli` | `PreToolUse` على `Bash` | off | ابوب أوامر `az`. | -| `block-helm` | `PreToolUse` على `Bash` | off | ابوب أوامر `helm`. | -| `block-gh-pipeline` | `PreToolUse` على `Bash` | off | ابوب عمليات `gh` التي تسبب طفرات: تشغيل workflow وإعادة تشغيل وإلغاء التشغيل وضم PR وإنشاء وحذف الإصدار وحذف الذاكرة وتعيين وحذف السر. الأوامر الفرعية للقراءة فقط مثل `gh pr view` غير مطابقة. | +`block-failproofai-commands` **مفعل دائماً**. تم إدراجه أعلاه لتوضيح المعلومات، لكنه يتسجل عند كل تقييم سواء ظهر في مجموعة السياسات المفعلة لديك أم لا، ولا يمكن تعطيله أو إيقافه مؤقتاً — فالحارس الذي يمكن للعامل إيقاف الإنفاذ عنه ليس حارساً. -## Git — `git` +الموصى به مقصود أن يكون أضيق من **الكل**. سياسات البنية التحتية وسير العمل يمكن أن تقاطع العمل الصحيح وينبغي تفعيلها للمستودعات والأجهزة التي تحتاجها. -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `block-push-master` | `PreToolUse` على `Bash` | on | منع الدفع المباشر إلى الفروع المحمية المكونة. | -| `block-force-push` | `PreToolUse` على `Bash` | off | منع الدفع القسري. يبقى `--force-with-lease` و`--force-if-includes` مسموحًا. | -| `block-work-on-main` | `PreToolUse` على `Bash` | off | منع الالتزامات والدمج على الفروع المحمية. | -| `warn-git-amend` | `PreToolUse` على `Bash` | off | تحذير قبل إعادة كتابة التزام باستخدام `--amend`. | -| `warn-git-stash-drop` | `PreToolUse` على `Bash` | off | تحذير قبل حذف أو مسح stashes دائمًا. | -| `warn-all-files-staged` | `PreToolUse` على `Bash` | off | تحذير على عمليات `git add -A` أو `git add .` أو `git add --all` الواسعة. | +## الأسرار والبيئة -## قاعدة البيانات — `database` - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `warn-destructive-sql` | `PreToolUse` على `Bash` | off | تحذير على `DROP` و`TRUNCATE` و`DELETE` بدون `WHERE` عبر عملاء قواعد البيانات المعروفة. | -| `warn-schema-alteration` | `PreToolUse` على `Bash` | off | تحذير على عمليات `ALTER TABLE` المعروفة للأعمدة وإعادة التسمية. | - -## الحزم والنظام — `packages-system` - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `warn-package-publish` | `PreToolUse` على `Bash` | off | تحذير قبل النشر إلى npm و PyPI و crates.io و RubyGems وسجلات مماثلة. | -| `warn-global-package-install` | `PreToolUse` على `Bash` | off | تحذير قبل تثبيت الحزم بشكل عام. | -| `prefer-package-manager` | `PreToolUse` على `Bash` | off | منع مدير حزم غير المفضل وتوجيه الوكيل لاستخدام الموجودة. | -| `warn-large-file-write` | `PreToolUse` على `Write` | off | تحذير أعلى عتبة حجم الملف المكونة. | -| `warn-background-process` | `PreToolUse` على `Bash` | off | تحذير على أنماط العمليات المنفصلة أو خلفية. | - -## سلوك الذكاء الاصطناعي — `ai-behavior` - -| السياسة | المحفز | القيمة الافتراضية | النتيجة | -| --- | --- | --- | --- | -| `warn-repeated-tool-calls` | `PreToolUse` | off | تحذير عند استدعاء الأداة نفسها ثلاث مرات أو أكثر بمعاملات متطابقة. | - -## سير العمل — `workflow` - -الخمسة كلهم يعملون على `Stop` ومعطلة بشكل افتراضي. - -| السياسة | القيمة الافتراضية | النتيجة | +| السياسة | الحافز | النتيجة | | --- | --- | --- | -| `require-commit-before-stop` | off | ارفض الإكمال بينما تبقى أعمال مسارة غير مرتكبة. | -| `require-push-before-stop` | off | ارفض الإكمال بينما تبقى الالتزامات محلية فقط. | -| `require-pr-before-stop` | off | اطلب طلب سحب للفرع الحالي. | -| `require-no-conflicts-before-stop` | off | اطلب دمج نظيف ضد الفرع الأساسي المكون. | -| `require-ci-green-before-stop` | off | اطلب النجاح في فحوصات CI على التزام HEAD الحالي، مع تجاهل الأشغال القديمة على الالتزامات السابقة. | +| `sanitize-jwt` | `PostToolUse` | إخفاء JWTs من مخرجات الأدوات قبل أن يراها النموذج. | +| `sanitize-api-keys` | `PostToolUse` | إخفاء مفاتيح OpenAI و Anthropic و GitHub و AWS و Stripe و Google الشائعة. | +| `sanitize-connection-strings` | `PostToolUse` | إخفاء سلاسل اتصال قواعد البيانات التي تحتوي على بيانات اعتماد. | +| `sanitize-private-key-content` | `PostToolUse` | إخفاء أجسام مفاتيح PEM الخاصة. | +| `sanitize-bearer-tokens` | `PostToolUse` | إخفاء رموز الترخيص. | +| `protect-env-vars` | `PreToolUse` على أدوات الغلاف | منع الأوامر التي تفرغ متغيرات البيئة. | +| `block-env-files` | `PreToolUse` | منع قراءة وكتابة ملفات `.env`. | +| `block-read-outside-cwd` | `PreToolUse` على أدوات القراءة أو glob أو grep أو shell | إبقاء القراءة داخل دليل العمل للجلسة. | +| `block-secrets-write` | `PreToolUse` على أدوات الكتابة | منع الكتابة إلى أسماء ملفات المفاتيح السرية والبيانات الاعتمادية الشائعة. | + +## الأوامر الخطيرة والبنية التحتية + +| السياسة | الحافز | النتيجة | +| --- | --- | --- | +| `block-sudo` | `PreToolUse`, `PermissionRequest` | منع `sudo` إلا إذا تطابق نمط السماح. | +| `block-curl-pipe-sh` | `PreToolUse` | منع النصوص البرمجية المحملة الموجهة مباشرة إلى الغلاف. | +| `block-rm-rf` | `PreToolUse` | منع أنماط الحذف العودية الكارثية. | +| `block-failproofai-commands` | `PreToolUse`, `PermissionRequest` | **مفعل دائماً، لا يمكن تعطيله.** منع كل استدعاء CLI من Failproof AI، والإيقاف الذاتي، وإلغاء تثبيت مدير الحزم. | +| `block-kubectl` | `PreToolUse` | حماية أوامر Kubernetes. | +| `block-terraform` | `PreToolUse` | حماية أوامر Terraform و OpenTofu. | +| `block-aws-cli` | `PreToolUse` | حماية أوامر AWS CLI. | +| `block-gcloud` | `PreToolUse` | حماية أوامر Google Cloud CLI. | +| `block-az-cli` | `PreToolUse` | حماية أوامر Azure CLI. | +| `block-helm` | `PreToolUse` | حماية أوامر Helm. | +| `block-gh-pipeline` | `PreToolUse` | حماية عمليات GitHub CLI الطافرة لسير العمل والتشغيل والدمج والإصدار والذاكرة والعمليات السرية. | + +## سلامة Git وقاعدة البيانات + +| السياسة | الحافز | النتيجة | +| --- | --- | --- | +| `block-push-master` | `PreToolUse` | منع الدفع المباشر إلى الفروع المحمية المُعدَّلة. | +| `block-force-push` | `PreToolUse` | منع الدفع القسري؛ يبقى `--force-with-lease` مسموحاً بالتطبيق الحالي. | +| `block-work-on-main` | `PreToolUse` | منع الالتزامات والدمج على الفروع المحمية. | +| `warn-git-amend` | `PreToolUse` | تحذير قبل إعادة كتابة التزام باستخدام `--amend`. | +| `warn-git-stash-drop` | `PreToolUse` | تحذير قبل حذف أو مسح المخزن المؤقت نهائياً. | +| `warn-all-files-staged` | `PreToolUse` | تحذير على `git add -A` أو `git add .` أو `git add --all` الواسع. | +| `warn-destructive-sql` | `PreToolUse` | تحذير على `DROP` و `TRUNCATE` و `DELETE` بدون `WHERE` من خلال عملاء قواعد البيانات المعروفة. | +| `warn-schema-alteration` | `PreToolUse` | تحذير على عمليات `ALTER TABLE` المعروفة لأعمدة وإعادة تسمية. | + +## الحزم وسلوك النظام وحلقات العامل + +| السياسة | الحافز | النتيجة | +| --- | --- | --- | +| `warn-package-publish` | `PreToolUse` | تحذير قبل النشر إلى السجلات. | +| `warn-global-package-install` | `PreToolUse` | تحذير قبل التثبيت العام للحزمة. | +| `prefer-package-manager` | `PreToolUse` | إرشاد العامل لاستخدام مدير حزم مسموح. | +| `warn-large-file-write` | `PreToolUse` على أدوات الكتابة | تحذير فوق حد حجم الملف المُعدَّل. | +| `warn-background-process` | `PreToolUse` | تحذير على أنماط العمليات الخلفية المنفصلة أو طويلة العمر. | +| `warn-repeated-tool-calls` | `PreToolUse` | تحذير بعد ثلاث مكالمات أدوات متطابقة أو أكثر. | -هذه تحتاج إلى إطار عمل يتم استهلاك حكم `Stop` الخاص به. ليس كل إطار عمل: +## سير عمل نهاية المهمة -| إطار العمل | `Stop` | -| --- | --- | -| claude و codex و copilot و cursor و openclaw و factory و devin و antigravity | تم التحقق من الحجب: يفرض الرفض دورة أخرى | -| pi | ملاحظة. يتم نقل السبب إلى الدورة التالية كتعليمات وليس كبوابة | -| goose و hermes | لم يتم تثبيت أي hook `Stop`، لذا هذه الخمسة لا تعمل أبدًا | -| opencode | لم يتم التحقق. `Stop` ليست من بين الأحداث التي يستهلك opencode حكمًا منها | +تتطلب هذه السياسات حزام يصدر حدث `Stop` متوافق. -تعمل عمليات Cursor Cloud Agent VM على لا أي stop hooks، لذا فإن جلسة Cursor هناك غير مغطاة على الرغم من أن Cursor المحلي ليس كذلك. - - -تعود سياسات `warn-*` بـ `instruct`، وليس `deny`. (`prefer-package-manager` هي الاستثناء بين الأسماء غير `block-*`: تعود بـ `deny`، لذا تحجب على كل إطار عمل يستهلك حكم `PreToolUse` — وهي الاثني عشر جميعها.) على Hermes و Goose و على Pi و OpenClaw و Factory خارج قناة `Stop` وعلى Antigravity خارج `Stop` و`UserPromptSubmit`، `instruct` تنخفض إلى السماح بالإضافة إلى ملاحظة على stderr — لا يتم إخبار الوكيل. `UserPromptSubmit` الخاص بـ Antigravity هي قناة حقيقية ثانية: يتم حقن التعليمات كرسالة مؤقتة قبل تشغيل النموذج. - +| السياسة | النتيجة | +| --- | --- | +| `require-commit-before-stop` | رفض الإنجاز بينما يبقى العمل المتتبع غير ملتزم. | +| `require-push-before-stop` | رفض الإنجاز بينما تبقى الالتزامات محلية فقط. | +| `require-pr-before-stop` | طلب طلب دمج للفرع الحالي. | +| `require-no-conflicts-before-stop` | طلب دمج نظيف مقابل فرع القاعدة المُعدَّل. | +| `require-ci-green-before-stop` | طلب اكتمال فحوصات CI في HEAD الحالي بنجاح. | ## مرجع المعاملات -قم بتكوين المعاملات تحت كائن `policyParams` الخاص بالنطاق المختار. يتم التحقق من الأنواع بواسطة كل سياسة. +قم بتكوين المعاملات تحت كائن `policyParams` للنطاق المحدد. يتم التحقق من الأنواع من قبل كل سياسة. -| السياسة | المعامل | النوع والقيمة الافتراضية | +| السياسة | المعامل | النوع والافتراضي | | --- | --- | --- | -| `sanitize-api-keys` | `additionalPatterns` | `pattern[]`, `[]`؛ تحتوي الإدخالات على `regex` و`label` | +| `sanitize-api-keys` | `additionalPatterns` | `pattern[]`, `[]`؛ الإدخالات تحتوي على `regex` و `label` | | `block-read-outside-cwd` | `allowPaths` | `string[]`, `[]` | | `block-sudo` | `allowPatterns` | `string[]`, `[]` | | `block-rm-rf` | `allowPaths` | `string[]`, `[]` | -| Infrastructure blockers | `allowPatterns` | `string[]`, `[]` | +| حاجبات البنية التحتية | `allowPatterns` | `string[]`, `[]` | | `block-secrets-write` | `additionalPatterns` | `string[]`, `[]` | | `block-push-master` | `protectedBranches` | `string[]`, `["main", "master"]` | | `block-work-on-main` | `protectedBranches` | `string[]`, `["main", "master"]` | @@ -153,6 +112,7 @@ failproofai policies add FailproofAI/policies --category git,database ```json { + "enabledPolicies": ["block-sudo", "block-push-master"], "policyParams": { "block-sudo": { "allowPatterns": ["sudo systemctl status"] @@ -164,10 +124,6 @@ failproofai policies add FailproofAI/policies --category git,database } ``` - -اسم السياسة المكشوف كمفتاح `policyParams` يتم احترامه لـ `FailproofAI/policies` فقط. بالنسبة لأي حزمة أخرى فإن المفتاح هو `pack///` — حزمة غريب تعلن اسم السياسة نفسه تحصل على افتراضات المخطط، وليس معاملات لك. - - -نمط السماح يوسع ما قد يفعله الوكيل. اختبر الترميز والمتغيرات الدقيقة للأمر على إطار العمل الهدف قبل نشره عبر الأسطول. + نمط السماح يوسّع ما قد يفعله العامل. اختبر الرمزنة الدقيقة وأنماط الأوامر على الحزام المستهدف قبل نشره عبر الأسطول. \ No newline at end of file diff --git a/docs/ar/policies/builtin.mdx b/docs/ar/policies/builtin.mdx index cd530086f..d6f1ecc55 100644 --- a/docs/ar/policies/builtin.mdx +++ b/docs/ar/policies/builtin.mdx @@ -1,100 +1,58 @@ --- +--- title: "السياسات المدمجة" -description: "استخدم الحماية الموثوقة للحالات الشائعة لفشل الوكلاء، وفعّل ما تريده منها." +description: "تفعيل الحماية المحتفظ بها للأخطاء الشائعة في وكلاء الذكاء الاصطناعي." icon: "library" --- -المدمجات هي 39 سياسة موثوقة تغطي تسع فئات من حالات فشل الوكلاء. جميعها ما عدا واحدة **تُسلّم كحزمة**، `FailproofAI/policies`، بنفس الطريقة التي يتم بها تسليم سياسات أي شخص آخر. الحزمة لا تشحن حزمتها الخاصة، لذا التثبيت الجديد لا ينفذ شيئاً إلى أن تختاره: - -```bash -failproofai policies add FailproofAI/policies -``` - -يفعّل هذا الإعدادات الافتراضية للحزمة — 10 من 38 سياسة التي تحملها الحزمة. الـ 39 سياسة هي `block-failproofai-commands`، وهي مفعّلة بغض النظر: يتم شحنها مجمّعة في الحزمة، وتسجيل في كل تقييم، ولا يمكن تعطيلها أو إيقافها. لا يمكن لحزمة أن تعلن `alwaysOn`، ولهذا السبب هذا الحماية لا تسير في مسار الحزمة. - -## ما تغطيه الفئات التسع - -| الفئة | `--category` slug | السياسات | -| --- | --- | --- | -| تنقية البيانات | `sanitize` | 5 | -| البيئة | `environment` | 3 | -| الأوامر الخطرة | `dangerous-commands` | 5 | -| أوامر الهياكل الأساسية | `infra-commands` | 7 | -| Git | `git` | 6 | -| قاعدة البيانات | `database` | 2 | -| الحزم والنظام | `packages-system` | 5 | -| سلوك الذكاء الاصطناعي | `ai-behavior` | 1 | -| سير العمل | `workflow` | 5 | +تغطي السياسات المدمجة معالجة الأسرار والملفات البيئية وأوامر shell التدميرية والفروع المحمية وأدوات السحابة والبنية التحتية ونشر الحزم والاستدعاءات المتكررة وفحوصات سير عمل نهاية المهمة. -هذه هي أعداد الفهرس المجمّع، وتصل إلى 39. الحزمة تحمل 38 منها، لأن `block-failproofai-commands` هي `alwaysOn` ولا تسير في مسار الحزمة — لذا `--category dangerous-commands` تختار الأربع الأخرى. - -خذ جزء بدلاً من الإعدادات الافتراضية: - -```bash -failproofai policies add FailproofAI/policies --category git,database -failproofai policies add FailproofAI/policies --policy block-rm-rf -failproofai policies add FailproofAI/policies --all -``` - -## اقرأ الفهرس قبل أن تختاره +## تفعيل والتحقق من سياسة مدمجة + + 1. قم بتثبيت السياسة على جهاز متصل باستخدام واجهة سطر الأوامر المحلية. + 2. قم بتشغيل إجراء اختبار آمن في الوكيل المقيس. + 3. انتقل إلى **Observe → policy** وقم بالتصفية حسب اسم السياسة أو بيئة الجهاز أو القرار. + 4. افتح الجلسة المرتبطة لتأكيد إدخال الأداة المطابق والسبب المُرجع. + + ```bash - failproofai policies show FailproofAI/policies failproofai policies + failproofai policy add block-rm-rf --cli claude --scope project + failproofai config --status ``` - `policies show` يقرأ البيان المنشور — كل سياسة، مجمّعة حسب الفئة، موضحة كافتراضية أو اختيارية — دون تنزيل أو استيراد كود الحزمة. `failproofai policies` يسرد ما هو مفعّل على هذه الآلة: الملفات المخصصة، ملفات الاتفاقية، الحزم المثبتة والتعيينات السحابية. لا يحتوي على قسم مدمج، لذا يجيب على "ما هو مفعّل هنا"، وليس أبداً "ما هو موجود". - - - تصفح نفس الفهرس في متصفح، بدون CLI، في [befailproof.ai/policy-hub](https://befailproof.ai/policy-hub/). كل حزمة لها صفحة في `/policy-hub///` وكل سياسة لها صفحة في `/policy-hub////`. - - - 1. ثبّت السياسة على آلة متصلة باستخدام CLI المحلي. - 2. شغّل إجراء اختبار آمن في الوكيل المجهز بأداة. - 3. اذهب إلى **Observe → policy** وصفّ حسب اسم السياسة أو بيئة الآلة أو القرار. - 4. افتح الجلسة المرتبطة للتأكد من مطابقة إدخال الأداة والسبب المُرجع. + أزلها باستخدام `failproofai policy remove block-rm-rf --cli claude --scope project`. -## فعّل واحدة أو أطفئها +اعرض قائمة بالسياسات المتاحة في النسخة المثبتة لديك: ```bash -failproofai policies add block-rm-rf --cli claude --scope project -failproofai policies remove block-rm-rf --cli claude --scope project +failproofai policies ``` -`policies add` و `policies remove` تأخذ بالضبط **واحدة** اسم سياسة. قم بتشغيلها بدون اسم على الإطلاق وستحصل على منتقي، مع ما هو مفعّل بالفعل محدد. للعديد من الأسماء في نفس الوقت، استخدم نموذج التثبيت: +قم بتفعيل سياسة واحدة لمشروع: ```bash -failproofai policies --install block-sudo block-force-push \ - --cli claude codex --scope project +failproofai policy add block-rm-rf --scope project ``` - - على آلة بدون حزمة مثبتة، `failproofai policies add ` يجلب `FailproofAI/policies` من إصدارها على GitHub لتلبية الاسم — لذا هذا الأمر الأول يحتاج الشبكة. - - -## ليس كل سياسة تفرض على كل جهاز - -السياسة تغيير السلوك فقط حيث يستهلك الجهاز الحكم للحدث الخاص به. حالتان تستحقان التحقق قبل أن تعتمد على مدمج: +قم بتفعيل عدة سياسات لأجهزة اختبار معينة: -| الحدث | حيث يتم التحقق من أن الرفض يغيير السلوك | -| --- | --- | -| `PreToolUse` | جميع 12 أجهزة | -| `Stop` | claude, codex, copilot, cursor, openclaw, factory, devin, antigravity. لا يتم تثبيت `Stop` hook على goose أو hermes، pi ينقل السبب إلى الدور التالي بدلاً من ذلك، و opencode لم يتم التحقق منه | - -لذا السياسات الخمس `require-*-before-stop` في فئة سير العمل يمكن تفعيلها على آلة وتظل لا تُطلق أبداً، اعتماداً على الوكيل الذي يعمل هناك. VMs Cursor Cloud Agent لا تشغل أي stop hooks على الإطلاق. - -سياسات `warn-*` و `prefer-*` تُرجع `instruct` بدلاً من `deny`. على Hermes و Goose، وخارج قناة `Stop` على Pi و OpenClaw و Factory و Antigravity، يتدهور `instruct` إلى allow بالإضافة إلى ملاحظة على stderr: المشغل يراها في السجلات، الوكيل لا. +```bash +failproofai policies --install block-sudo block-force-push \ + --cli claude codex --scope project +``` -بعض السياسات تقبل معاملات. راجع الوصف، طابق النطاق والافتراضي قبل النشر — سياسة تحمي سير عمل واحد قد تحجب عمليات صحيحة في آخر. +بعض السياسات تقبل معاملات أو تحمل علامة beta. راجع الوصف ونطاق المطابقة والسلوك الافتراضي قبل الطرح. قد تحمي سياسة ما سير عمل واحد وتحظر العمليات الصحيحة في آخر. - - جميع 39 سياسة مدمجة، حسب الفئة، مع مشغلاتها والإعدادات الافتراضية والمعاملات. + + راجع جميع السياسات الحالية البالغ عددها 40، ومحفزاتها والأساس الموصى به والمعاملات. - `failproofai config` يسلك كل وكيل مدعوم في نطاق المستخدم ولا يختار أي سياسات — لا يحتوي على علم `--scope`. مرر `--scope project` إلى `failproofai policies add` أو `failproofai policies --install` فقط عندما تنتمي التوقعات حقاً إلى مستودع واحد. + يُفضل نطاق المشروع للتوقعات المحددة للمستودع ونطاق المستخدم لمتطلبات الأمان على مستوى الجهاز. \ No newline at end of file diff --git a/docs/ar/policies/custom.mdx b/docs/ar/policies/custom.mdx index 32e3ca8d3..7a6d93fd0 100644 --- a/docs/ar/policies/custom.mdx +++ b/docs/ar/policies/custom.mdx @@ -1,52 +1,73 @@ --- --- title: "السياسات المخصصة" -description: "اكتب قاعدة للسلوك المحدد لوكيلك أو سير عملك." -icon: "code-2" +description: "اكتب سياسة لنمط فشل فريد لسير عمل وكيلك." +icon: "shield-plus" --- -تحقق من [الكتالوج المدمج](/ar/policies/builtin-catalog) قبل كتابة سياسة. القاعدة المراجعة عادة ما تكون أأمن من واحدة جديدة. +أنشئ ملف ينتهي بـ `policies.js` أو `policies.mjs` أو `policies.ts` ضمن `.failproofai/policies/`. تُحمّل ملفات الاتفاقية تلقائياً على نطاق المشروع والمستخدم. -## ابدأ من سياسة تعمل +## اختبر السياسة قبل النشر على السحابة -```bash -failproofai publish --init guards.mjs -failproofai policies -i -c ./guards.mjs -``` + + + 1. ثبّت السياسة المخصصة على آلة اختبار واحدة وأطلق إجراءً متطابقاً وعدم تطابق شرعياً. + 2. انتقل إلى **Observe → policy** وقارن بين القرارين. + 3. افتح كل جلسة مرتبطة وتحقق من أن حمل الحدث يحتوي على أدلة كافية للقاعدة. + 4. عندما يكون السلوك صحيحاً، انقل المصدر المراجع إلى **Admin → policy editor** وأصدر نسخة. -الكتل الأساسية تحجب `git push --force`. عدّلها، اطلب من وكيلك أن يحاول الإجراء المحجوب، وافحص **Policies → Activity**. + + + ```bash + failproofai policies --install --custom ./security.policies.ts \ + --cli claude --scope project + failproofai policies + ``` -```js + ملفات الاتفاقية ضمن `.failproofai/policies/` تُحمّل بدون `--custom`. احفظ أمر التثبيت الصريح في CI عندما يجب أن يفشل التحقق على وحدة معطوبة. + + + +```ts import { customPolicies, allow, deny } from "failproofai"; customPolicies.add({ - name: "protect-production", - description: "Production changes need a human", - match: { events: ["PreToolUse"], toolNames: ["Bash"] }, - fn: async (ctx) => - String(ctx.toolInput?.command ?? "").includes("production") - ? deny("Ask a human before changing production.") - : allow(), + name: "protect-production-paths", + description: "Block writes to production configuration", + match: { events: ["PreToolUse"] }, + fn: async (ctx) => { + if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow(); + const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/"); + if (path.split("/").includes("production")) { + return deny("Writes to production configuration require approval."); + } + return allow(); + }, }); ``` -تعيد السياسة `allow()` أو `deny(message)` أو `instruct(message)`. استخدم `deny` عندما يجب إيقاف الإجراء؛ لا يمكن لكل نطاق توصيل تعليمات مرة أخرى للوكيل. +يتطابق هذا مع `production/config.yml` و `/srv/production/config.yml` و `/srv/production` و `C:\\production\\config.yml` لكل من `Write` و `Edit`. لا يتطابق مع أسماء مثل `production-backup` لأن `production` يجب أن تكون قطعة مسار كاملة. -## تحميل تلقائي +تحقق وثبّت ملفاً صريحاً: -ضع الملفات المسماة `*policies.js` أو `*policies.mjs` أو `*policies.ts` تحت: +```bash +failproofai policies --install --custom ./security.policies.ts +``` -- `.failproofai/policies/` لمشروع واحد. -- `~/.failproofai/policies/` لمستخدمك. +سياق السياسة يتضمن نوع الحدث والحمل المُعايير واسم الأداة والإدخال ومعادات الجلسة والمعاملات ومصدر CLI عند توفره. ## اختبر مسارات الفشل -اختبر كلاً من الإجراء غير الآمن والعمل المشروع الذي يبدو مشابهاً. تأكد من أن القرار جاء من سياستك وليس من قاعدة أخرى. - -أزل ملفات الاختبار الصريحة باستخدام: +قم بالتحقق بعد تغيير ملف الدخول أو أي وحدة محلية يستوردها: ```bash -failproofai policies -u -c +failproofai policies --install --custom ./security.policies.ts --scope project ``` -عندما تكون السياسة جاهزة، [انشر حزمة](/ar/policies/publish-a-pack) أو [نشرها عبر Cloud](/ar/policies/deploy). \ No newline at end of file +مسار CLI الصارم يفشل للملفات المفقودة وأخطاء بناء الجملة والواردات غير المحللة والاستثناءات على مستوى أعلى والمهلات الزمنية لتحميل الوحدة. في وقت الإنفاذ، يتم تسجيل ملف مخصص معطوب وتخطيه حتى تتمكن السياسات المدمجة من المتابعة. تعامل مع أي تحذير تحميل كفقدان للإنفاذ المتوقع والتنبيه عليه في سجلات الإنتاج. + +استخدم أسماءً فريدة عالمياً عبر السياسات الصريحة والاتفاقية والمُدارة من السحابة. اجعل دوال السياسة حتمية، وقيّد الاستدعاءات الخارجية بمهل زمنية قصيرة، وأرجع `allow` أو `instruct` أو `deny` مقصود على كل مسار. + + + السياسة المخصصة هي كود إنفاذ. اختبر الحقول المفقودة وأسماء الأدوات البديلة والمدخلات المشوهة—ليس فقط المطابقة المتوقعة. + \ No newline at end of file diff --git a/docs/ar/policies/deploy.mdx b/docs/ar/policies/deploy.mdx index 3c74d1a67..8cc7efbea 100644 --- a/docs/ar/policies/deploy.mdx +++ b/docs/ar/policies/deploy.mdx @@ -1,55 +1,52 @@ --- --- title: "نشر السياسات" -description: "راقب سياسة على نشاط الوكيل الفعلي، ثم طبّقها أو تراجع عنها." +description: "إطلاق نسخة سياسة تم مراجعتها إلى الأجهزة المقصودة." icon: "cloud-upload" --- -نشّر سياسة تمت مراجعتها على جهاز واحد في كل مرة. ابدأ في وضع المراقبة. +يربط النشر نسخة واحدة أو أكثر من السياسات بمجموعة مستهدفة من الأجهزة المسجلة. -## الطرح من سطر الأوامر +## تطبيق نشر -```bash -fp policies test ./rule.mjs --tool Bash --command "git push --force" --expect deny -fp policies publish no-force-push ./rule.mjs -fp fleet deploy --add no-force-push:observe -fp guardrails summary --since 24h --machine -fp fleet deploy --add no-force-push:enforce -``` + + + 1. انتقل إلى **Admin → enforcement**، ابحث عن الجهاز، وقم بتوسيع صفه. + 2. اختر **edit**، أضف نسخة السياسة المراجعة، واختر **observe** أو تأثيرها الإجباري. + 3. طبّق التغيير، ثم انتظر فحص الجهاز التالي وتأكد من حالة نشره وتغطيته. + 4. انتقل إلى **Observe → policy** للفحص القرارات المباشرة. -يقيّم وضع المراقبة السياسة الفعلية ويسجل القرارات غير المسموحة، لكنه لا يحجب الوكيل. + ![محرر نشر الجهاز مع نسخ السياسات، وتأثيرات الفرض والمراقبة، وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png) + + + قم بالنشر من واجهة سطر الأوامر باستخدام `fp fleet`. راجع مجموعة النتائج قبل تطبيقها — يطبع `deploy` الخطة الكاملة ويسأل **فقط على محطة تفاعلية بدون `--json`**. تحت `--json`، مع `--yes`، أو مع إعادة توجيه stdin (خطوة CI، سكريبت، وكيل يشغل shell) يتم التطبيق فوراً بدون خطة وبدون مطالبة — لذا قم بتشغيل `fp fleet show ` أولاً إذا كنت تريد المراجعة: - - إن استخدام `--add no-force-push` بدون إضافة يطبق السياسة فوراً. أضف `:observe` لطرح خادع. - - -إذا تسبب التطبيق في مشاكل: - -```bash -fp fleet history -fp fleet rollback -``` + ```bash + fp fleet list + fp fleet show + fp fleet deploy --add no-force-push + ``` -## النشر من لوحة التحكم + يعرض `fp fleet diff ` النية مقابل التسليم (يُقرأ الجهاز كـ `behind` حتى يقوم بالاستطلاع التالي)، `fp fleet history ` يسرد الأجيال، و `fp fleet rollback ` يستعيد واحداً — يرفض إذا كان هذا الجيل يسمي سياسة تم تعطيلها أو حذفها. -1. انتقل إلى **Admin → enforcement**. -2. افتح الجهاز المستهدف. -3. أضف إصدار السياسة مع التأثير **observe**. -4. طبّق النشر. -5. راجع النتائج تحت **Observe → policy**. -6. رقّ نفس الإصدار إلى **enforce** عندما تكون المطابقات صحيحة. + تحقق من الجهاز نفسه باستخدام `failproofai config --status`، واستخدم `fp sessions --env production --since 24h` و `fp events --event-type hook_completed` بعد النشر للتحقق من وصول النشاط إلى Cloud. + + -![محرر نشر الجهاز مع إصدارات السياسات وتأثيرات enforce و observe وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png) + + + قم بنشر نسخة تم مراجعتها، وليس مسودة قابلة للتغيير، بدءاً بجهاز غير إنتاجي أو مجموعة صغيرة يمكنك فحص جلساتها. + + + راجع التطابقات والأسباب والأدوات المتأثرة والإيجابيات الكاذبة بدون حجب العمل. + + + قم بالترقية بعد المطابقات المرصودة التي تفصل الإجراءات غير الآمنة عن الإجراءات الصحيحة، ثم تأكد من أن كل جهاز مقصود قد سحب النشر ويقدم التقارير عن القرارات. + + -## استبدال أو مرحلة مسبقة من مجموعة +تحتاج الأجهزة إلى القدرة على `policies:pull`. يتم التحكم في الإبلاغ عن الأحداث بشكل منفصل بواسطة `events:add`؛ تحقق من كليهما عندما تتوقع تحليل Cloud والفرض. -- `--remove ` يزيل سياسة واحدة. -- `--set ...` يستبدل مجموعة السياسات الكاملة. -- `--create` يحضّر نشراً قبل أن يتحقق الجهاز للمرة الأولى. -- `fp fleet diff ` يقارن الحالة المقصودة والمطبقة. - - - بدون Cloud، انشر حزمة باستخدام `failproofai publish --effect observe` وفتّش القرارات في لوحة التحكم المحلية. - - -تحتاج الأجهزة إلى `policies:pull` لاستقبال النشرات و `events:add` للإبلاغ عن القرارات. \ No newline at end of file + + إدارة الفرض هي سير عمل إداري في Cloud. لا تعامل مسارات الفرض للمسؤول الجذر فقط كنقاط نهاية API عادية للعملاء `/v1`. + \ No newline at end of file diff --git a/docs/ar/policies/failure-behavior.mdx b/docs/ar/policies/failure-behavior.mdx index dd8797e3f..a75a67cbc 100644 --- a/docs/ar/policies/failure-behavior.mdx +++ b/docs/ar/policies/failure-behavior.mdx @@ -1,49 +1,68 @@ --- --- -title: "سلوك فشل السياسة" -description: "افهم لماذا يرفض Failproof AI عندما لا يتمكن التقييم من الرد." +title: "سلوك الفشل" +description: "افهم ما يحدث عند عدم توفر تقييم السياسة أو daemon المحلي." icon: "shield-alert" --- -بعد الإعداد، خدمة `failproofaid` المحلية هي المُقيِّم الوحيد. إذا لم تتمكن من الرد، يتم رفض الإجراءات المحمية بدلاً من السماح بها بصمت. +تم تصميم Failproof AI بحيث يكون فشل الإنفاذ مرئياً بدلاً من السماح الصامت بعمل محفوف بالمخاطر. -## تشخيص حظر على مستوى الجهاز +## تشخيص كتلة مغلقة الفشل -```bash -failproofai config --status -systemctl status failproofaid@$USER # Linux -sudo launchctl print system/ai.failproof.failproofaid.$USER # macOS -``` + + + 1. انتقل إلى **Admin → enforcement** وافتح الآلة. + 2. تحقق من آخر تسجيل دخول، والنشر المعين، والنشر المبلغ عنه. + 3. انتقل إلى **Observe → policy** وافتح جلسة القرار المرفوض. + 4. تأكد مما إذا كان السبب يشير إلى إمكانية الوصول إلى daemon أم عدم التطابق في الإصدار أم السياسة نفسها. -قم بتشغيل `failproofai config` لإصلاح الخدمة أو تثبيت الإصدار المطابق. + + + ```bash + failproofai config --status + npm install -g failproofai@latest + failproofai config + ``` -يمكن أن يبدو الفشلان متشابهين: + إعادة تشغيل `failproofai config` يحدّث ويعيد تشغيل daemon بعد ترقية الحزمة. + + -| الفشل | المعنى | -| --- | --- | -| الخدمة غير متاحة | المقبس ليس لديه مُقيِّم عامل خلفه | -| عدم تطابق الإصدار | واجهة سطر الأوامر والخدمة لا تتفقان على البروتوكول | +على آلة تم تكوينها لاستخدام `failproofaid`، يكون daemon هو المقيّم الوحيد. إذا كان غير قابل للوصول أو كان إصدار البروتوكول الخاص به لا يطابق CLI، يفشل تقييم hook بشكل مغلق. يتم رفض الإجراء مع سبب يوجه المشغل إلى التحقق من daemon أو تحديثه. -كلاهما يرفض، لكن تقارير الحالة تفصل بينهما. +قبل تكوين daemon، تقيّم hooks السياسات أثناء المعالجة. بمجرد تسجيل تكوين daemon، لا يعود Failproof AI إلى تقييم ثاني بصمت عند فشل daemon. -## لن يتم تحميل حزمة +## الاستجابة لقرار مغلق الفشل -تحديد حزمة مفقودة أو مُعدَّلة أو غير صالحة يرفض الأحداث المغطاة بسياساتها المحددة. وهذا يمنع اختفاء حزمة مكسورة بينما يبدو الجهاز محمياً. +1. قم بتشغيل `failproofai config --status`. +2. إذا اختلفت الإصدارات، أعد تشغيل `failproofai config` بعد تحديث الحزمة. +3. إذا كان daemon غير قابل للوصول، افحص حالة الخدمة وسجلات الملف الشخصي المحلي. +4. استأنف عمل agent فقط بعد التأكد من أن مسار تقييم السياسة المعروف سليم. -`failproofai policies` يسمي الحزمة وخطأ التحميل. + + لا تحاول تكرار الإجراء المحظور بشكل متكرر. استجابة مغلقة الفشل تعني أن النظام لم يتمكن من إثبات أن الإجراء كان آمناً. + -```bash -failproofai policies -failproofai policies remove owner/repo -failproofai policies add owner/repo@ -``` +## لن يتم تحميل الحزمة -البيانات الوصفية غير القابلة للقراءة توسع الرفض الآمن بدلاً من تضييقه بناءً على البيانات التي لا يمكن الوثوق بها. +آلة تم إخبارها بفرض حزمة، ولا يمكنها تشغيلها، ترفض بدلاً من المتابعة بصمت. المحفز هو **توقع مسجل**، وليس توقع فارغ: آلة بدون حزم مثبتة تكون صامتة، بينما حزمة تم إعلانها ولن تُحل — أو تسجل أقل من ما يعلنه البيان الخاص بها — ترفض. -## ما يبقى متاحاً +الرفض **ضيق**، على عكس daemon غير قابل للوصول. daemon الذي لا يمكن الوصول إليه يعني أنه لم يحدث أي تقييم على الإطلاق، لذلك لا يمكن معرفة شيء آمن. حزمة لن تتحمل لديها مجموعة قابلة للعد من الحراس المفقودين، لأن كل سياسة معلنة تحمل `match` خاصة بها — لذلك ترفض فقط الأحداث والأدوات التي غطتها تلك السياسات، وكل شيء آخر يمضي قدماً. -لوحة المعلومات المحلية وأوامر الحالة لا تزال تعمل بينما يفشل تقييم السياسة. استخدمها لتحديد الخدمة أو الحزمة أو الإصدار الذي يحتاج إلى إصلاح. +لا تنطلق بسبب: - - لا تتجاوز قرار الإغلاق عند الفشل بحذف خدمة أو ملفات الحزمة. أصلح الخدمة أو أعد تثبيت الحزمة أو أزل التعيين من خلال واجهة سطر الأوامر بحيث يعود الجهاز إلى حالة معروفة. - \ No newline at end of file +- حزمة `observe`، التي تقيّم وتتجاهل بالبناء +- سياسات لم تأخذها، أو أوقفتها بشكل صريح +- حزمة لم يتلقاها المحمّل، حيث لا يمكن التمييز بين «لا تسجيلات» و تخطي متعمد +- توقف جلسة نشطة +- مهلة زمنية للتحميل، وهي عابرة — لحظة قرص واحدة بطيئة يجب ألا ترفض حتى يتدخل إنسان + +`UserPromptSubmit` **توجه** بدلاً من الرفض، مهما أعلنت السياسة المفقودة. رفض شامل سيأخذ معه ويغلقك خارج agent الذي يمكنه إصلاح المشكلة. + +### ماذا تفعل + +```bash +failproofai pack list +``` + +يسمي أي حزمة مثبتة لن يتم تحميلها، ويقول السبب، ويخرج برمز غير صفر. ثم إما أعد تثبيتها (`failproofai pack add `) أو أزلها (`failproofai pack remove `) — إزالتها تسحب التوقع، والرفض يتوقف معها. \ No newline at end of file diff --git a/docs/ar/policies/fleet.mdx b/docs/ar/policies/fleet.mdx index 94e203edf..5f2b83cb8 100644 --- a/docs/ar/policies/fleet.mdx +++ b/docs/ar/policies/fleet.mdx @@ -1,62 +1,53 @@ --- --- -title: "تغطية الأسطول" -description: "اطّلع على الأجهزة التي استقبلت وطبّقت السياسات المقصودة." +title: "نشر السياسات على الأجهزة" +description: "تعرّف على الأجهزة المسجلة والمحدثة والتي تفرض إصدارات السياسة المقصودة." icon: "network" --- -تقارن تغطية الأسطول ما خصصته السحابة مع ما طبّقه كل جهاز آخر مرة. +يجيب تغطية الأسطول على السؤال حول ما إذا كانت السياسة موجودة حيث توجد المخاطر. تتبع الأجهزة من خلال معرّف مستقر وتسمية يمكن قراءتها من قبل الإنسان، ثم قارن بين حالة النشر المخصصة والمُبلغ عنها. -## التحقق من جهاز +## التحقق من التغطية -```bash -failproofai config --status -failproofai flush --wait --timeout 120 -``` + + + 1. انتقل إلى **Admin → enforcement** واستعرض إجمالي الأجهزة التي تفرض وتراقب. + 2. ابحث عن جهاز حسب المعرّف أو التسمية، أو قم بالتصفية للأجهزة التي تفتقد سياسة. + 3. وسّع الصف لمقارنة السياسات المعينة والنشر المُبلغ عنه ووقت آخر تسجيل دخول والسجل. + 4. أعِد التحديث بعد فترة استطلاع الجهاز عندما يبقى النشر المطبق قيد الانتظار. -من السحابة: - -```bash -fp fleet list -fp fleet diff -fp fleet show -``` + ![أسطول الإنفاذ يعرض تغطية السياسة وحالة نشر الجهاز وتعيينات المراقبة والإنفاذ.](/images/dashboard/enforcement-fleet.png) + + + ```bash + failproofai config --status + failproofai config --machine-label checkout-runner-03 + failproofai flush --wait + ``` -يتطلب `fp fleet` جلسة تسجيل دخول، وليس مفتاح API. + استخدم `fp events --agent-id --since 24h` للتأكد من وصول نشاط وكيل الجهاز إلى السحابة. + + -| الأمر | ما يفعله | -| --- | --- | -| `fp fleet list` | اسرد الأجهزة وحالة النشر | -| `fp fleet show ` | اعرض مجموعة السياسات لجهاز واحد | -| `fp fleet deploy --add ` | أضف أو حدّث سياسة واحدة | -| `fp fleet deploy --remove ` | أزل سياسة واحدة | -| `fp fleet deploy --set ...` | استبدل المجموعة بأكملها | -| `fp fleet diff [machine]` | قارن الإصدارات المقصودة والمطبّقة | -| `fp fleet history ` | اسرد أجيال النشر | -| `fp fleet rollback ` | استعد جيلاً | -| `fp fleet rename "