@zaip-ai/cli 2.2.0 → 3.0.0

package/templates/.agents/dashboard/apps/frontend/dist/assets/dashboard-localization-Basaw1NR.js

@@ -0,0 +1,824 @@
+function e(e,n,r){let i=Object.entries(r).map(([n,r])=>{let i=n.split(`/`).at(-1)??n,a=e===`en-US`?`> Language: Portuguese (pt-BR). Current canonical guide; an English translation is not available.
+
+`+r:r;return{id:n,title:t(a,i),content:a}}).sort((t,n)=>t.title.localeCompare(n.title,e));return[{id:`readme`,title:`README · ZAIP-AIOS`,content:e===`en-US`?`# ZAIP-AIOS (6 Squads + 23 Agents)
+
+English | [Português](README.md)
+
+> **Bilingual maintenance / manutenção bilíngue:** \`README.md\` is the primary Portuguese source; keep this \`README-ENG.md\` as its corresponding English translation whenever either document is updated.
+
+## Quick overview
+
+ZAIP-AIOS is an operating system for autonomous work performed by AI agents. It coordinates 23 specialized agents, organized into six squads, within Codex.
+
+Agents plan, execute, review, test, and validate work under the orchestrator's coordination. Authorized execution continues until acceptance or an evidence- and budget-based blocked/failed outcome. Persistent permits indefinite execution by explicit choice; other presets have per-Task quotas. No preset guarantees success or expands authority for external actions.
+
+The approach seeks to reduce intervention, unnecessary context, and rework. The 34% and 62% figures below refer respectively to average cost per task and per hour in the illustrated historical series; they do not directly measure token reduction or guarantee savings in a new delivery.
+
+Although it originated in software work, ZAIP-AIOS also coordinates Operations, Growth, Marketing, Branding, and Sales work. The framework and Dashboard run locally without a VPS. Authentication, quotas, billing, and integrations depend on the selected host/provider; using a Codex subscription does not turn the estimated equivalent cost into API billing.
+
+<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Organizational structure of ZAIP-AIOS's six squads and 23 agents" width="100%">
+
+In practice, the system breaks down complex requests, organizes work, selects suitable agents, coordinates dependencies, tracks execution, and checks quality before a delivery is considered complete.
+
+The Dashboard centralizes the operation in one view, bringing together Tasks, SPECs, and PRDs, along with dependencies, blockers, execution time, token consumption, costs, reviews, and evidence produced throughout the process.
+
+<img src=".agents/config/src/dashboard_pt_1_visao_geral.png" alt="ZAIP-AIOS Dashboard, Overview" width="100%">
+
+In a comparative sample of autonomously executed tasks, ZAIP-AIOS showed an approximate 34% reduction in average cost per task and 62% in average cost per hour. The comparison covers the full work cycle—planning, execution, tests, reviews, and documentation—and results must be interpreted within the limits of the analyzed sample.
+
+<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Comparative analysis: average hourly cost fell from R$ 410 to R$ 154" width="900">
+
+The canonical source remains the repository's Git-native files. Requirements, decisions, implementations, and proof can be versioned; they enter remote history only after an explicitly authorized commit and publication. Secrets and private machine state stay outside that history.
+
+The Dashboard uses a local, disposable, rebuildable database only as a query and visualization layer. No critical information depends solely on it. In ZAIP-AIOS, a Task is not complete merely because an agent finished its execution: objective evidence must show that Acceptance Criteria and quality requirements were met.
+
+## Start here
+
+| If you want to… | Start with… |
+| --- | --- |
+| Install and obtain the first result | [One-command installation](#one-command-installation) |
+| See observed results | [Measured savings](#measured-savings-and-the-central-goal-per-task) |
+| Track work, costs, and quality | [Local Dashboard](#local-dashboard) |
+| Make a focused change | [Three ways to execute](#three-ways-to-execute) |
+| Plan a technical or product delivery | [PRD as the autonomy interface](#prd-as-the-autonomy-interface) |
+| Understand the method | [The six-step ZAIP method](#the-six-step-zaip-method) |
+| Learn about specialized agents | [Agent personas and routing](#agent-personas-and-routing) |
+| Consult technical contracts | [Technical and operational reference](#technical-and-operational-reference) |
+| Maintain the framework | [Framework development](#framework-development) |
+| Configure permissions safely | [Security with permission profiles](#security-with-permission-profiles) |
+| Assess release, support, and commercialization | [Production and commercial readiness](docs/PRODUCTION-COMMERCIAL-READINESS.md) |
+| Browse the 28 operational guides | [Complete handbook index](.agents/zaip-aios/INDEX.md) |
+
+### How to read this documentation
+
+Both READMEs are maintained in Portuguese and English. Dashboard Help loads
+the canonical English README; guides without translations show the current
+Portuguese source with a language notice, not stale parallel summaries.
+
+This README and the [handbook](.agents/zaip-aios/INDEX.md) describe this repository's source code. Effective configuration, host support, the installed package, and a qualified candidate are distinct dimensions. \`@latest\` points to the published version, which may not include local changes. Dashboard images illustrate prior states; they are not visual proof of the current candidate.
+
+Documentation changes do not approve a release. Consult the [qualification-limits record](docs/PRODUCTION-COMMERCIAL-READINESS.md#limites-conhecidos-da-qualificação) before promoting code; local tests, parity, CI, and production validation must be proven separately.
+
+For v3 delivery, the complete suite runs in signed local preparation (\`full-v2\`). GitHub verifies the exact package, installation and publication without repeating source tests on every push. Activation requires full local qualification and enrolled trust. One automatic installation smoke precedes npm publication; source checks and the remote matrix are manual, with no private-draft pilot. See the [quality and release guide](.agents/zaip-aios/guides/26-qualidade-e-release.md). Historical telemetry gaps remain explicit, without invented values or waived tests for new data.
+
+## One-command installation
+
+With Node.js 22.16.0 or later and npm, run installation at the root of the project that will receive ZAIP-AIOS. In a fresh installation, \`init\` uses the full (\`full\`) profile: it installs missing stack dependencies and prepares Terraform. Every profile checks distributed runtimes and prepares and validates local SQLite without a separate driver. Existing package versions are preserved, with a notice showing the installed and ZAIP-AIOS-configured versions:
+
+\`\`\`bash
+npx --yes @zaip-ai/cli@latest init --project-only
+node .agents/runtime/bin/zaip.mjs doctor --json
+\`\`\`
+
+These are the two steps for the first verified result: \`init\` installs the
+framework in the selected project without changing global Codex configuration,
+and \`doctor --json\` confirms the installed layout, checksums, and adapters. The
+result is ready only when the JSON returns \`"valid": true\`.
+
+Review the plan before writing to the project:
+
+\`\`\`bash
+npx --yes @zaip-ai/cli@latest init --project-only --dry-run
+\`\`\`
+
+Both commands use the profile saved in the project, or \`full\` if no choice exists. \`--yes\` before the package name accepts only the CLI's initial \`npx\` download; it does not force replacement of existing dependencies, files, or versions. It can be combined with any profile, for example \`npx --yes @zaip-ai/cli@latest init --profile lite\`. \`init --yes\`, after the package name, confirms replacement requested by \`--force\`. Use \`--force --yes\` only after reviewing the dry run; the installer creates a backup before replacement.
+
+### Installation profiles
+
+\`\`\`bash
+npx @zaip-ai/cli@latest init --profile dev-lite
+npx @zaip-ai/cli@latest init --profile lite
+\`\`\`
+
+| Profile | Command | Intended for |
+| --- | --- | --- |
+| Full (\`full\`, initial default) | \`npx @zaip-ai/cli@latest init\` | Development and infrastructure with Terraform |
+| Development (\`dev-lite\`) | \`npx @zaip-ai/cli@latest init --profile dev-lite\` | Application development without installing Terraform |
+| Operations (\`lite\`) | \`npx @zaip-ai/cli@latest init --profile lite\` | Growth and Ops without programming-stack packages or Terraform |
+
+All profiles include the framework, agents, skills, and Dashboard. The \`lite\` profile retains dependencies required by ZAIP itself; Node/npm are still needed to run the installer. \`full\` and \`dev-lite\` create \`package.json\` and a lockfile when the project has neither.
+
+The choice is saved in the project and honored by later upgrades. To enable development after a \`lite\` installation, run \`init --profile dev-lite\`; to include Terraform, run \`init --profile full\`. Moving to a smaller profile does not uninstall existing packages or tools. Use \`npx @zaip-ai/cli@latest init --profile lite\` to install that profile. Use \`--dry-run --profile full\` to inspect the change before installation.
+
+| Dependency | Function | Default version |
+| --- | --- | --- |
+| TypeScript | Language and typing | 7.0.2 |
+| Vite | Web build and development | 8.1.4 |
+| Astro | Site framework | 7.2.4 |
+| Redis | JavaScript Redis client | 6.2.1 |
+| BullMQ | Queues and jobs | 6.2.0 |
+| Hono | Web API | 4.12.34 |
+| React | Web UI | 19.2.7 |
+| React DOM | React DOM rendering | 19.2.7 |
+| Local Node.js | Stack runtime, prepared automatically when needed | 22.23.2 (conditional) |
+| SQLite | Local Dashboard database | Built into Node.js; varies by runtime |
+| Terraform CLI | Infrastructure provisioning; only in the \`full\` profile | 1.16.1 for managed installation |
+
+The command installs the latest public ZAIP-AIOS version, prepares missing dependencies for the selected profile, and preserves existing package versions. Source changes reach \`@latest\` only after publication to npm. Installation includes the Dashboard, Rules, skills, and Codex/Claude configuration. Run the same command again to update managed files without deleting history.
+
+The Redis package includes only the JavaScript client; configure the server separately. The \`full\` profile reuses compatible Terraform or prepares a local installation with official download and SHA-256 validation. Configure cloud credentials separately. Providers declared in \`.tf\` files are downloaded when you run \`terraform init\`; installing ZAIP neither provisions resources nor runs \`terraform apply\`.
+
+After installation, consult the [operational index](.agents/zaip-aios/INDEX.md) to get started.
+
+## How the layers complement each other
+
+| Type | Name | Responsibility |
+| --- | --- | --- |
+| **AI Model** | **GPT-5.6 (default)** | Main model for reasoning, programming, tool use, agent coordination, and complex task execution. Configuration remains open to testing, comparison, and substitution by other models. |
+| **AI Harness** | **Codex (default)** | Official harness connecting the LLM to the terminal, tools, subagents, worktrees, sandbox, hooks, skills, and browser. Its alignment with the model's training provides greater optimization, predictability, and use of model capabilities. |
+| **AI Coding methodology** | **ZAIP-AIOS** | Git-native autonomous, multi-agent engineering system. It turns PRDs and SPECs into executable Tasks, DAGs, and Changes; automates tests and reviews; and keeps decisions, executions, evidence, costs, and changes traceable in Git. |
+
+The model provides intelligence, Codex provides the official execution environment, and ZAIP-AIOS adds method, governance, and verifiable memory. Together they define **what must be done, how work is organized, which rules apply, and which proof permits it to be declared complete**. The reference experience is optimized for GPT-5.6 and Codex, while alternate models and hosts remain available for comparison and compatibility through portable artifacts.
+
+## Agent personas and routing
+
+ZAIP-AIOS brings together 23 specialized agents so that each request is handled by the most suitable capability. The goal is not to use every agent in each delivery, but to form the smallest group able to execute, review, and prove the result with quality.
+
+Technical identities remain separate from visible personas. Names and roles can therefore be displayed and configured in the Dashboard without compromising internal routing contracts. Selection considers the primary decision or outcome, specialization, scope, and risk; references and inputs support the work but do not alone change the executor. Authorship, context, and history remain traceable.
+
+### The 23 agents
+
+| Photo | # | Persona / role | Specialty |
+| :---: | ---: | --- | --- |
+| <img src=".agents/config/src/1%20-%20Dave%20-%20Product%20Owner.png" alt="Dave, Product Owner" width="400"> | 1 | Dave / Product Owner | Resolves the DAG and delegates |
+| <img src=".agents/config/src/2%20-%20Rafa%20-%20Tech%20Lead.png" alt="Rafa, Tech Lead" width="400"> | 2 | Rafa / Tech Lead | Generic delivery, SPEC, and dashboard/local work |
+| <img src=".agents/config/src/3%20-%20Leo%20-%20Software%20Engineer.png" alt="Leo, Software Engineer" width="400"> | 3 | Leo / Software Engineer | End-to-end generic Task |
+| <img src=".agents/config/src/4%20-%20Bia%20-%20Product%20Manager.png" alt="Bia, Product Manager" width="400"> | 4 | Bia / Product Manager | PRD creation/refinement and product analysis |
+| <img src=".agents/config/src/5%20-%20Gui%20-%20Quality%20Assurance%20Lead.png" alt="Gui, Quality Assurance Lead" width="400"> | 5 | Gui / Quality Assurance Lead | Restricted terminal outcome |
+| <img src=".agents/config/src/6%20-%20Nanda%20-%20Principal%20Engineer.png" alt="Nanda, Principal Engineer" width="400"> | 6 | Nanda / Principal Engineer | Independent review |
+| <img src=".agents/config/src/7%20-%20Dani%20-%20Integration%20Engineer.png" alt="Dani, Integration Engineer" width="400"> | 7 | Dani / Integration Engineer | Integration and combined gates |
+| <img src=".agents/config/src/8%20-%20Ana%20-%20Quality%20Auditor.png" alt="Ana, Quality Auditor" width="400"> | 8 | Ana / Quality Auditor | Independent audit |
+| <img src=".agents/config/src/9%20-%20Lia%20-%20Technical%20Writer.png" alt="Lia, Technical Writer" width="400"> | 9 | Lia / Technical Writer | Faithful summaries, transcript analysis, and source-grounded documentation |
+| <img src=".agents/config/src/10%20-%20Gabi%20-%20Data%20Analyst.png" alt="Gabi, Data Analyst" width="400"> | 10 | Gabi / Data Analyst | Data analysis |
+| <img src=".agents/config/src/11%20-%20Tati%20-%20Refactoring%20Specialist.png" alt="Tati, Refactoring Specialist" width="400"> | 11 | Tati / Refactoring Specialist | Safe refactoring, migration, and modularization |
+| <img src=".agents/config/src/12%20-%20Doug%20-%20Frontend%20Developer.png" alt="Doug, Frontend Developer" width="400"> | 12 | Doug / Frontend Developer | Frontend and accessibility according to \`DESIGN.md\` |
+| <img src=".agents/config/src/13%20-%20Will%20-%20Backend%20Developer.png" alt="Will, Backend Developer" width="400"> | 13 | Will / Backend Developer | API, backend, and modules |
+| <img src=".agents/config/src/14%20-%20Jonny%20-%20Website%20Developer.png" alt="Jonny, Website Developer" width="400"> | 14 | Jonny / Website Developer | Sites and landing pages, SEO, GEO, and agent readiness |
+| <img src=".agents/config/src/15%20-%20Manu%20-%20Product%20Designer.png" alt="Manu, Product Designer" width="400"> | 15 | Manu / Product Designer | \`DESIGN.md\`, Design System, tokens, and catalog |
+| <img src=".agents/config/src/16%20-%20Dan%20-%20Cloud%20Engineer.png" alt="Dan, Cloud Engineer" width="400"> | 16 | Dan / Cloud Engineer | Cloud infrastructure, Terraform, Docker, and environments |
+| <img src=".agents/config/src/17%20-%20Luis%20-%20Security%20Auditor.png" alt="Luiz, Security Auditor" width="400"> | 17 | Luiz / Security Auditor | Independent technical security audit |
+| <img src=".agents/config/src/18%20-%20Lucia%20-%20Marketing%20Analyst.png" alt="Lucia, Marketing Analyst" width="400"> | 18 | Lucia / Marketing Analyst | Marketing planning, copy, and asset preparation |
+| <img src=".agents/config/src/19%20-%20Renata%20-%20Compliance%20Specialist.png" alt="Renata, Compliance Specialist" width="400"> | 19 | Renata / Governance & Compliance Specialist | Internal HR, operational legal, policy, privacy, vendor, and risk artifacts |
+| <img src=".agents/config/src/20%20-%20Clara%20-%20Operations%20Specialist.png" alt="Clara, Operations Specialist" width="400"> | 20 | Clara / Operations Generalist | Bounded documents, presentations, spreadsheets, processes, and comparisons outside mandatory specialties |
+| <img src=".agents/config/src/21%20-%20Sarah%20-%20Branding%20Specialist.png" alt="Sarah, Branding Specialist" width="400"> | 21 | Sarah / Branding Specialist | Brand strategy and governance, Brandbook, archetypes, semantic differentiation, and brand architecture |
+| <img src=".agents/config/src/22%20-%20Aaron%20-%20Sales%20Specialist.png" alt="Aaron, Sales Specialist" width="400"> | 22 | Aaron / Sales Specialist | Internal sales process, qualification, playbooks, scripts, and SDR-to-closer handoffs |
+| <img src=".agents/config/src/23%20-%20Robert%20-%20Growth%20Strategist.png" alt="Robert, Growth Strategist" width="400"> | 23 | Robert / Growth Strategist | Growth strategy, RevOps, experiments, and data- and financial-impact-oriented recommendations |
+
+The [agent catalog](.agents/zaip-aios/guides/18-catalogo-de-agentes.md) brings together the specialties and responsibilities of available ZAIP-AIOS agents.
+
+### Organizational squads
+
+<img src=".agents/config/src/Zaip%20AIOS%20Squads.png" alt="Organizational structure of ZAIP-AIOS's six squads and 23 agents" width="100%">
+
+The six squads make responsibility structure easy to see: **Product** (Dave, Bia, and Manu), **Admin & Operations** (Clara, Renata, and Lia), **Development** (Rafa, Leo, Jonny, Will, Doug, and Tati), **Delivery Assurance** (Nanda, Gui, Ana, and Dani), **Infra & Security** (Dan and Luiz), and **Growth — Sales, Marketing and Branding** (Robert, Gabi, Lucia, Sarah, and Aaron).
+
+This is an organizational view, not a routing rule. The orchestrator selects an agent by capability, declared scope, risk, and a Task's write scopes; being in the same squad grants no access, does not replace canonical selection, and does not require collaboration.
+
+Each request can begin as a Task, a SPEC, or a PRD. In every entry point, intent is turned into structured work with an objective, scope, quality criteria, and traceable steps.
+
+Codex remains the execution environment, while ZAIP-AIOS adds organization, governance, and visibility to the development cycle. Through the Dashboard, you can track delivery progress, dependencies, blockers, and results.
+
+When run with a ChatGPT/Codex account, consumption follows that account's terms. When compatible telemetry and pricing exist, the Dashboard shows an estimated API-equivalent cost for comparison and planning; other providers can have their own billing models.
+
+## Local Dashboard
+
+The Dashboard turns ZAIP-AIOS technical history into a clear operational view. In one place it shows current work, observed costs, quality coverage, blockers, and the relation between intent, execution, and outcome.
+
+<img src=".agents/config/src/dashboard_pt_1_visao_geral_este_mes.png" alt="ZAIP-AIOS Dashboard, monthly overview" width="100%">
+
+Git-native records remain the official source. Everything shown on the screens can be rebuilt from canonical files and project configuration, without creating a parallel database or external infrastructure dependency.
+
+**How the local Dashboard projection works**
+
+Canonical ZAIP records remain in the standard \`.agents/records\` structure. To speed queries and views, the Dashboard rebuilds disposable SQLite as a *read model*. That file is neither source of truth nor canonical storage: it is only a rebuildable local projection.
+
+No SQLite server, DBeaver, or external database is needed. \`.local/sqlite/\` is the central per-workspace directory for locally managed SQLite databases; several stable names can coexist according to purpose. The Dashboard uses exactly \`.local/sqlite/zaip-aios-dashboard.sqlite\`, without copies per port, PID, hash, or generation. WAL, SHM, and JOURNAL are normal auxiliary files for an open database. Disposable fixtures live in \`.local/sqlite/tests/<fixture>/\` with automatic cleanup; isolated workspaces use their own \`.local/sqlite/\`; internal databases of external tools follow those tools' storage conventions. Opening or refreshing the Dashboard does not authorize global Run reconciliation; that is a separate operation requiring confirmation.
+
+### Kanban
+
+It organizes PRDs, SPECs, and Tasks by stage, highlighting execution, verification, completion, criticality, time, tokens, and observed cost.
+
+<img src=".agents/config/src/dashboard_pt_2_kanban.png" alt="ZAIP-AIOS Dashboard, Kanban" width="100%">
+
+The Work (Kanban) and Work (List) views switch between stage reading and detailed comparison. Both retain the All Tasks, General Unified View, PRDs, SPECs, and Standalone Tasks filters, supporting analysis of status, origin, risk, Runs, Sub-Runs, time, tokens, cost, and coverage. Each item can be opened to investigate blockers and consult its traceable history.
+
+### Cost Monitor
+
+It consolidates tokens, duration, estimated equivalent cost, and coverage by period and work unit without turning missing telemetry into zero.
+
+<img src=".agents/config/src/dashboard_pt_3_monitor_custos.png" alt="ZAIP-AIOS Dashboard, Cost Monitor" width="100%">
+
+The monitor consolidates tokens, time, cost, and coverage by Run, Task, SPEC, and PRD. It supports comparison of conversation, planning, execution, new work, and rework, and identifies consumption averages and concentrations by day, month, or year. When Codex uses account tokens or quota instead of API billing, the module calculates the **estimated API-equivalent cost** in USD and BRL whenever compatible measurement and pricing exist. The estimate supports management and comparison but is never shown as actual billing. Unobserved values remain \`unknown\`, never artificially zero.
+
+**Telemetry technical contract**
+
+Codex telemetry uses sanitized local spool, one \`InvocationSummary\` per invocation, and Git-tracked monthly-manifest chunks. Period queries use manifests first and fall back to the Run projection when no applicable summary exists. Incomplete coverage remains explicit for every metric. [Git-native Codex telemetry](.agents/zaip-aios/guides/27-telemetria-git-native.md) documents contracts, storage, integrity, recovery, and rollout limits.
+
+### Traceability
+
+It relates intent, planning, execution, decisions, validations, and evidence to explain where every result came from.
+
+<img src=".agents/config/src/dashboard_pt_4_rastreabilidade.png" alt="ZAIP-AIOS Dashboard, Traceability" width="100%">
+
+It correlates PRD, Requirements, SPEC, Change, Task, Execution, Runs, Decisions, tests, reviews, evals, and Evidence in a logical traceability graph. The view details the six method stages and shows which documents and proof support each result. Each record receives an identifier, date, and time when part of lifecycle or telemetry; evidence stays linked and Git also preserves chronology. This supports audit, resumption, rework analysis, and intent-versus-execution comparison. Projections may be rebuilt and optimized; Git-native telemetry compaction preserves IDs, relationships, metrics, coverage, and hashes without versioning prompts or responses.
+
+## Project settings
+
+The Dashboard brings project settings together in a screen connected to the canonical \`.agents/config/project.yaml\` file. Before saving, settings are schema-validated, preserving an explicit definition of the framework, available capabilities, and an overview of project artifacts.
+
+### Platform configuration
+
+Platform configuration shows ZAIP-AIOS activation state and a summary of agents, squads, skills, Rules, hooks, and database. The same view shows the project's reference documents and indicates which already exist, keeping technical configuration and documentation visible in one context.
+
+<img src=".agents/config/src/dashboard_pt_configuracao_plataforma.png" alt="ZAIP-AIOS Dashboard, platform configuration" width="100%">
+
+### v3 autonomy presets
+
+The sources being prepared for v3 add a per-Task preset, separate from
+installation and assurance:
+
+| Preset | Product executions per Task | Replans | Replanning models |
+| --- | --- | --- | --- |
+| Essential (\`essential\`) | 4: 1 initial + 3 repairs | 1 | Sol/high; never automatic Astra |
+| Balanced (\`balanced\`, new default) | 10: 1 initial + 9 repairs | 3 | Sol/high → Astra/high → Astra/high |
+| Persistent (\`persistent\`, opt-in) | Unlimited | Unlimited | Sol/high first; Astra/high thereafter |
+
+Merge into \`.agents/config/project.yaml\`, or select **Autonomy preset** in
+Dashboard **Project settings** and save:
+
+\`\`\`yaml
+autonomy:
+  version: 1
+  preset: balanced
+\`\`\`
+
+The durable ledger reserves before managed dispatch; restart or resume does
+not reset the quota. Changes apply to new Tasks. There is no time-based
+abandonment or automatic reduction of acceptance criteria. Persistent may
+consume credits indefinitely until human cancellation; permissions stay unchanged.
+
+A SPEC with ten Balanced Tasks allows up to 100 executions (10 initial +
+90 repairs) and 30 replans; individual tests and internal Calls are not attempts.
+Missing verification/safe conclusion ends as \`blocked\`; a proven technical
+impediment ends as \`failed\`. Independent branches remain eligible.
+
+**Current boundary:** counters are enforced in the managed runtime, not on
+external \`spawn_agent\` calls made directly by Codex. New projects use
+\`execution.runtime: managed\`: managed PRDs/SPECs and direct standalone Tasks.
+Saving a preset does not invoke a provider. Legacy Tasks need explicit migration
+without resetting consumption. See [autonomy and its guarantees](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+
+### Development stack
+
+The development stack describes each responsibility separately, with technology, exact version, and package, image, or service reference. In this project, the contract includes TypeScript, Node.js, Hono, Kysely, PostgreSQL via Supabase, Supabase Auth + Storage, Redis, and BullMQ, keeping development choices recorded alongside project configuration.
+
+<img src=".agents/config/src/dashboard_pt_configuracao_plataforma_stack.png" alt="ZAIP-AIOS Dashboard, development stack" width="100%">
+
+## The cost that matters: completing the task
+
+The price of a call or model alone does not represent the real cost of AI-assisted development. A delivery can involve understanding, context reading, implementation, tests, fixes, review, validation, and documentation. ZAIP-AIOS therefore measures **the cost to complete the work**, tracking Runs, phases, and rework by Task, SPEC, and PRD.
+
+A practical way to analyze total cost is:
+
+\`\`\`text
+completed-task cost = model + tools + human time + rework + defect cost
+\`\`\`
+
+## PRD as the autonomy interface
+
+A PRD governs a complete initiative without turning every technical decision into a new manual step. It records the expected outcome, organizes necessary deliveries, and leaves room for human review before execution.
+
+When a user says **“Help me think about a PRD”**, the system keeps the interaction as a planning conversation.
+
+When they say **“Create a PRD”**, the AI asks up to five important questions per turn for no more than three turns. It then creates:
+
+- a PRD in \`draft\` state
+- the necessary technical SPECs
+- a \`PreparedPlan\`
+- a summarized list of Tasks
+
+Technical decisions that can be delegated are made and recorded by the AI.
+
+**Planning, decomposition, and command details**
+
+### SPEC organization
+
+By default, each PRD uses only one SPEC to save resources.
+
+A new SPEC should be created only when a capability can be independently and concurrently implemented and validated. When parts of the work depend on one another, they remain in the same SPEC and are organized by the Task DAG.
+
+In the current runtime, a PRD materializes a deterministic child Execution for each eligible SPEC: its dependencies remain inside the SPEC and its write scopes do not conflict with any other branch. Each child runs with its own coordinator, state, and handoff; in \`autonomy-v1\`, recovery quotas remain per stable Task, under a queue bounded by effective parallelism and a single parent invocation ledger; the PRD Execution waits for terminal states, integrates candidates in the parent handoff, and only then applies cross-SPEC validation and finalization. SPECs with external dependencies or scope conflicts remain in the global coordinating DAG.
+
+Before a PRD reaches \`ready\`, Tasks are only work definitions, not yet executing.
+
+**“Make ready to execute”**, **“Finalize the PRD”**, and **“Complete the PRD”** create Tasks, Changes, and Executions in \`planned\` state but do not start implementation.
+
+**“Execute”** acts on the smallest item named by the user: a Task, SPEC, or complete PRD.
+
+### Decomposition limit
+
+The 1-to-5 scale defines the PRD decomposition limit. It is not a required target.
+
+* Level 1 covers a single vertical flow
+* Levels 2 to 4 require independent capabilities with separate contracts and write scopes
+* Level 5 should be used only in exceptional cases with five similar, independent implementations
+
+When capabilities depend on one another, work must remain in the same SPEC. Projects with more than five capabilities must be split into other PRDs or record an exception.
+
+### Command behavior
+
+The \`implemente\` (“implement”) command considers the current work state:
+
+* with no defined target, it opens a planning Conversation
+* in \`draft\`, it completes the plan
+* in \`ready\`, it starts execution
+* in active or failed states, it continues, resumes, or starts rework
+
+The \`desenvolva\`, \`melhore\`, and \`aprimore\` (“develop”, “improve”, and “enhance”) commands always return to planning or rework.
+
+A canceled PRD cannot be changed. When necessary, a new rework PRD is created, preserving the link and audit history.
+
+### Execution tracking
+
+Every PRD or SPEC creation is linked to its responsible Run through \`creation_run_id\`.
+
+Time, tokens, and cost are aggregated whenever this information is available or reconciled. Without sufficient data, values remain \`unknown\` or \`null\`.
+
+Overview retains the compact **Estimated cost** card. When coverage is incomplete,
+the accessible description and tooltip explain coverage without an icon. The
+subtitle allocates known spend across the selected task count and recorded hours;
+these are estimated allocation rates, not averages of complete per-task costs.
+Missing costs are not imputed. Each rate independently displays \`—\` only when its
+denominator is unavailable or zero, without hiding the other valid rate.
+The subtotal is not the full account cost or a bill. Observed
+zero remains zero, while missing measurements remain unavailable. Unexecuted Task
+drafts remain in the work list, outside the executable Kanban stages and operational
+indicators that exclude drafts.
+
+## Quality and evidence
+
+Quality is part of the definition of done. Each delivery combines tests, review, and checks proportionate to its risk, with objective proof of Acceptance Criteria. Evidence connects approved validations to the Task, Change, Execution, Run, Acceptance Criteria, and candidate. The [review guide](.agents/zaip-aios/guides/07-revisao-e-validacao.md) explains how to record the procedure actually executed and its result.
+
+The current contract adds \`confirmed\`, \`limited\`, \`pending\`, \`failed\`, and \`not_applicable\` observations without replacing Validation/Evidence V2. The CLI validates structure and links; it does not run the declared command, inspect images, or query services automatically. Technical proof is not equivalent to visual proof, real integration, or production proof. Isolated or pending observations do not approve a delivery.
+
+New Validation, Evidence, Observation, and Run-event records reject known credential patterns before persistence without repeating a sensitive value in the error. Use sanitized locators and results; protection does not certify that text is free of every secret or personal datum. Historical records remain readable and are not rewritten automatically. To reduce cycles without lowering quality, choose early a scenario that can reveal a wrong direction. Repeat after a concrete change or a result requiring correction, not merely because time passed. The same unavailable tool has finite fallback and an explicit pending state; proof sufficiency remains the executor/reviewer's responsibility. See the [canonical observable-evidence contract](.agents/skills/zaip-skill-change/references/observable-evidence.md).
+
+Tests, reviews, checks, and Evidence make project evolution more predictable: they raise confidence in changes, make reviews easier, and keep decisions, validations, and improvements fully traceable.
+
+## Measured savings and the central goal per task
+
+The analyses below show cost reductions **measured in the comparative sample** from complementary perspectives: average cost per Task and average cost per hour. The charts and table detail values, calculations, and the interpretation of each indicator. Results confirm reduction in the analyzed series, but must not be generalized to every Task, model, or repository without a new equivalent comparison.
+
+### Cost-per-task analysis
+
+This chart follows the cost of each Task in the two compared ranges. The initial mean is **R$ 67 per task**; in the later range it becomes **R$ 44**. The **34.3%** reduction (presented as approximately 34%) represents the lower average cost to complete a work unit in the observed sample.
+
+<img src=".agents/config/src/analise_comparativa_reducao_custo_por_tarefa.png" alt="Comparative analysis: average cost per task fell from R$ 67 to R$ 44" width="900">
+
+### Cost-per-hour analysis
+
+This chart presents the same comparison from the hourly perspective. Average cost falls from **R$ 410 per hour** to **R$ 154 per hour**, a **62.4%** reduction (approximately 62%). This complements the Task analysis by showing that the reduction also holds when cost is observed per hour.
+
+<img src=".agents/config/src/analise_comparativa_reducao_custo_por_hora.png" alt="Comparative analysis: average hourly cost fell from R$ 410 to R$ 154" width="900">
+
+Each indicator measures a different part of the flow. Percentages must not be added because they can reflect simultaneous optimizations in the same execution. Context and payload metrics remain reproducible measurements of the **18/08/2026** snapshot; they do not automatically describe the current population of skills or the repository.
+
+The first two rows are financial results observed in the comparative series. The others isolate payload and navigation gains that help explain how the flow can reduce cost, cycles, and rework.
+
+| What is reduced | What it represents | Baseline without optimization | With ZAIP-AIOS | Savings | Metric status |
+| --- | --- | ---: | ---: | ---: | --- |
+| **Average cost per task** | Average Task cost in the two ranges of the comparative series. | **R$ 67** | **R$ 44** | **34%** | **Observed measurement** in the presented comparison (exact reduction: 34.3%). |
+| **Average cost per hour** | Average hourly cost in the two ranges of the comparative series. | **R$ 410** | **R$ 154** | **62%** | **Observed measurement** in the presented comparison (exact reduction: 62.4%). |
+| **Context delivered to the agent for one Task** | Relevant Rules, Requirements, and artifact pack entering the work prompt. | 7,980 tokens | **1,593 tokens** | **80.0%** | Reproducible measurement. |
+| **Recurring operational navigation** | One round of four queries to locate active Changes, Tasks, Executions, and Runs. | 101,924 tokens | **10,199 tokens** | **90.0%** | Reproducible measurement; also reduces the pagination limit. |
+| **Instructions available to the agent** | 13/07/2026 snapshot of the then-queryable catalog (26 skills). | 1,091 tokens | **599 tokens** | **45.1%** | Reproducible snapshot measurement; it is not the current skill count. |
+
+### Comparison methodology
+
+Evidence of savings is based on cohorts of equivalent Tasks observed in two scenarios—for example, standard Codex and Codex + ZAIP-AIOS—with the same model, repository, Acceptance Criteria, and observation window. This equivalence keeps the comparison focused on the effect of the workflow.
+
+The indicators included in the analysis are:
+
+- tokens and equivalent API cost of all calls through completion;
+- duration and number of cycles/retries;
+- human review and correction time;
+- rework rate and defects found after delivery;
+- coverage of tests, reviews, and Acceptance Criteria evidence.
+
+The Cost Monitor preserves unknown values as \`unknown\`/\`null\` and does not turn missing telemetry into zero cost. This keeps provider, rework, or quality costs that have not yet been observed visible in the results. The methodology and its supporting records are in [the token and performance audit](analysis/verificacao-auditoria-tokens-performance-zaip-aios-2026-07-13.md).
+
+The \`zaip cost cohort --input <arquivo.json> --json\` command calculates comparable cohorts from observed billed costs and their provenance. The calculation contract requires USD currency, source, timestamp, a *quality floor*, a terminal attempt, and a single equivalent baseline identity. If a required dimension is missing or inconsistent, savings remain \`null\`, preserving the comparison's integrity.
+
+## Comparison with leading competing frameworks
+
+This section preserves a historical snapshot, not an up-to-date market study or production certification. The scores below do not replace qualification of the current candidate and were not recalculated in this documentation revision.
+
+This snapshot uses a comparative audit consolidated on August 6, 2026, positioning each product based on signals found in code, configuration, architecture, tests, and documentation. The methodology combines ten equally weighted criteria: each topic receives 0 to 10 points, and the final score, from 0 to 100, is their direct sum. In this scale, 9–10 indicates a clear reference in the criterion; 7–8, a strong and competitive offering; 5–6, a relevant but still partial capability; and 0–4, little evidence or low emphasis in the analyzed snapshot. The detailed matrix makes the composition of the scores transparent and allows updates as products evolve.
+
+| Product | Score /100 | Score rationale | Competitive positioning |
+|---|---:|---|---|
+| ZAIP-AIOS | **95** | Leads technically in this local snapshot by combining SDD, clean architecture, and Evidence-based quality with multiagent orchestration, security, context, and financial observability per Task in the same auditable lifecycle. | Complete platform for software engineering with agents, combining specification, execution, validation, security, and observability in a traceable lifecycle. |
+| Traycer | 83 | Connected coding agents, agent-to-agent architecture/review loops, CLI/terminal, and worktrees are strong; cost per Task and execution on a subscription host were not reproduced. | More specialized than OpenClaw for orchestrating coding agents, without replacing product validation. |
+| AIOX Core | 82 | Spec pipeline, dev/QA, worktrees, recovery, memory, and Codex/Cursor/Claude integrations support the flow; hooks have uneven parity and there is no cost per Task. | Broad development platform with strong DX, but less direct than Traycer. |
+| Kilo Code | 80 | Coding agent for VS Code, JetBrains, and CLI, with Debug, Review, self-correction, and \`kilo run --auto\`; telemetry exists, but cost per Task was not demonstrated. | First-class programming DX, with evidence limitations in isolation and recovery. |
+| TLC Spec-Driven | 80 | Adaptive SDD skill with AC→test, coverage matrix, independent verifier, discrimination sensor, and local lessons; the contract is strong, but enforcement depends on the agent/host. | Very strong in traceability and verification; self-referenced benchmark without raw data and without telemetry/cost per Task. |
+| Roo Code | 79 | VS Code with Code, Architect, and Debug modes, refactoring, history/resume, and worktrees; no consolidated cost per Task. | Very strong editor-first fit, with partial operational governance. |
+| Superpowers | 78 | TDD, worktree, subagent, review, and debugging skills make the programming playbook consistent; its guarantees remain instructional and behavioral tests depend on an external repository. | Strong discipline for coding agents, without a typed lifecycle or cost per Task. |
+| OpenClaw | 73 | Codex-native subagents, isolated sessions, sandbox, and tests are strong, but the multichannel assistant gateway does not demonstrate the same coding-first IDE/CLI flow. | Reference for isolation and general operation; below Traycer, Kilo, and Roo in the programming snapshot. |
+| Hermes | 71 | Retry, memory, and usage/pricing support coding features, but the platform is general-purpose rather than coding-first; cost per Task is not demonstrated. | Broad autonomous product, not automatically equivalent to a specialized development agent. |
+| OpenSpec | 70 | Delta specs, schemas, CLI, workspaces, and tests structure change evolution; verification is optional/partly heuristic. | Specialist in spec management, not a multiagent runtime, with no cost per Task. |
+| OpenCode | 60 | TUI/CLI, editing/patches, commands, LSP, MCP/providers, permissions, and SQLite sessions provide a lean, extensible foundation for terminal programming. | Direct alternative for terminal development, with opportunities to expand multiagents, lifecycle, tests, and cost per Task. |
+
+**Consult the technical matrix of the ten criteria**
+
+| Topic (0–10) | ZAIP | OpenClaw | Traycer | Kilo | Hermes | AIOX | Roo Code | OpenCode | TLC Spec-Driven | Superpowers | OpenSpec |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| T1 — SDD and traceability | 10 | 6 | 7 | 6 | 6 | 9 | 6 | 3 | 9 | 8 | 9 |
+| T2 — Plan–edit–test–fix loop | 9 | 7 | 9 | 10 | 7 | 9 | 9 | 8 | 9 | 9 | 6 |
+| T3 — Multiagents and isolation | 10 | 9 | 9 | 8 | 7 | 9 | 8 | 4 | 8 | 9 | 5 |
+| T4 — Architecture and repository | 10 | 8 | 9 | 8 | 7 | 8 | 8 | 8 | 7 | 7 | 8 |
+| T5 — Tests, review, and evidence | 10 | 9 | 9 | 9 | 8 | 9 | 9 | 5 | 9 | 9 | 8 |
+| T6 — Recovery and idempotency | 10 | 7 | 9 | 7 | 7 | 8 | 7 | 6 | 8 | 8 | 7 |
+| T7 — Supply chain | 9 | 8 | 8 | 8 | 8 | 7 | 8 | 6 | 7 | 7 | 6 |
+| T8 — Codebase memory | 9 | 8 | 9 | 8 | 9 | 9 | 8 | 7 | 9 | 8 | 8 |
+| T9 — Telemetry/cost per programming task | 9 | 6 | 5 | 6 | 6 | 6 | 6 | 4 | 5 | 4 | 4 |
+| T10 — CLI/IDE DX, debug, review, setup, and Codex-first | 9 | 5 | 9 | 10 | 6 | 8 | 10 | 9 | 9 | 9 | 9 |
+
+## From conversation to executable work
+
+The ZAIP-AIOS framework turns natural language into structured engineering. The user can send a short message, hold a refinement conversation, or provide the transcript of a long audio recording explaining context, constraints, and the desired outcome. The framework evaluates complexity, dependencies, breadth, and risk to propose an appropriate entry point: a Task for direct work, a SPEC for a technical delivery with multiple Tasks, or a PRD for a product initiative composed of one or more SPECs. The \`lite\`, \`standard\`, or \`critical\` risk level determines the required depth of planning, review, security, and evidence; every artifact remains open to human review.
+
+This makes it possible to move beyond a free-form conversation without falling into *vibe coding*: read-only questions and analyses remain Conversations without a Task; action requests become executable work. Before mutation, intent is converted into requirements, acceptance criteria, scope, dependencies, and write scopes, and a Task with a root orchestration Run enters Execution. See [Lifecycle of Conversations, Tasks, SPECs, and PRDs](.agents/zaip-aios/guides/28-lifecycle-completo.md).
+
+## The six-step ZAIP method
+
+| Stage | Artifacts | What happens |
+| --- | --- | --- |
+| **1. Definition** | PRD + Requirements | Records the objective, context, audience, constraints, expected outcome, and Acceptance Criteria that define the work. |
+| **2. Planning** | SPEC + Changes | Describes scope, solution, architecture, risks, and planned changes before execution, following SDD. |
+| **3. Execution** | Tasks + DAG + Executions + Runs | Coordinates Tasks, dependencies, agents, and produced files; records each attempt and its observable consumption. |
+| **4. Decisions** | Decisions (Human + AI / Planning + Execution) | Preserves human and AI decisions made during planning, execution, review, and repair, with context and consequences. |
+| **5. Verification** | Tests + Reviews + Evals + Checks | Runs quality mechanisms and compares observed results against requirements and Acceptance Criteria. |
+| **6. Evidence** | Evidence + Results + Traceability | Collects, records, and relates proof produced by verification to Tasks, Changes, Runs, and Acceptance Criteria; work is completed only when evidence is sufficient and reproducible. |
+
+The method keeps intent separate from execution. PRD and SPEC explain the intended delivery; Change, Task, Execution, and Run record how work was performed; Decisions explain why significant paths were chosen; Verification runs tests, reviews, evals, and checks; and Evidence preserves observed results and their relationship to Acceptance Criteria. Thus, “completed” is a state demonstrated by a diff, results, and reproducible evidence, not merely declared by an agent.
+
+## Complete execution chain
+
+The concepts below form the technical vocabulary used to connect intent, planning, execution, and proof without losing history.
+
+**Consult the complete lifecycle glossary**
+
+| Concept | Responsibility |
+| --- | --- |
+| **Rule** | Durable rule for behavior, architecture, security, context, or quality that Codex must follow. |
+| **Requirement** | Verifiable product obligation accompanied by Acceptance Criteria. |
+| **PRD** | Product Requirements Document that governs an initiative and organizes one or more SPECs. |
+| **SPEC** | SDD technical specification detailing the solution, scope, risks, Changes, Tasks, and DAG. |
+| **Change** | Living narrative of a planned and executed change: decisions, affected files, deviations, tests, evidence, rollout, rollback, and outcome. |
+| **Task** | Smallest executable unit, with objective, risk, priority, dependencies, write scopes, and acceptance criteria. |
+| **DAG** | Acyclic graph that orders dependencies, identifies safe parallelism, and prevents execution outside the required sequence. |
+| **Execution** | Interaction or delivery unit correlated with the observable turn: \`interaction\` records conversation/definition; \`delivery\` coordinates materialized work. Idempotency depends on observed turn identity; continuation may reuse the current delivery. |
+| **Run / Sub-Run** | An intake or orchestrator-agent Run has \`parent_run_id: null\`; a Sub-Run is each subagent call related by \`parent_run_id\`. New records use \`run_role: intake\\|orchestrator\\|subagent\`; each call fixes its model and effort and aggregates its internal Calls. |
+| **Decision** | Human or AI decision with context, selected alternative, reason, consequences, and rollback possibility. |
+| **Evidence** | Proof associated with the Task and Acceptance Criteria: test, diff, review, check, report, or reproducible result. |
+| **Eval** | Deterministic or rubric-based evaluation measuring quality, regression, adherence, and performance. |
+
+## Three ways to execute
+
+1. **Task-first:** executes one independent Task for direct, well-bounded changes.
+2. **SPEC:** executes a set of related Tasks coordinated by a DAG and governed by the same technical specification.
+3. **PRD:** executes a complete initiative by selecting one or more SPECs, each with its Changes, Tasks, and dependencies.
+
+This progression allows a simple start, adding planning only when breadth, dependencies, or risk justify a larger structure.
+
+**Technical execution and assurance policies**
+
+Conversation and standalone Task principals preserve manual host selection and prefer direct work. When delegation is necessary, disclose that children may use different models/efforts under ZAIP policy; they need not inherit the principal. Model and effort remain fixed per Run, with observed configuration separate from planned selection. Automatic selection requests \`standard\`; unobserved host capabilities cannot be assumed. See the [model policy](.agents/zaip-aios/guides/23-orquestracao-de-modelos.md).
+
+### Astra policy
+
+Essential never selects Astra automatically, including children or fallback. Its sole exception is a standalone principal with Astra selected manually by the user. Balanced replans use Sol/high, Astra/high, and Astra/high; in the third block Astra/high may also execute repairs without expanding the quota. Persistent retains that progression without an overall cap.
+
+Replanners are isolated and do not edit product files; executor, reviewer, and Gui are distinct roles. Automatic Astra uses only \`high\`, never replaces review/finalization, and depends on managed dispatch. The old cap of three read-only Astra diagnoses remains only in the legacy contract without \`autonomy\`; it does not limit Persistent. Context and assurance follow the domain: content needs sources/briefing, engineering needs verified behavior. Real savings must be measured, not inferred from a preset.
+
+Intake correlates the observable turn with the Execution. \`prepare\` validates the plan without authorizing implementation; \`ready\` materializes prepared work and \`execute\` starts authorized delivery. Every delivery and delegated interaction requires an eligible executor (or authorized direct Task root) and \`zaip-agent-finalizer\` last. A read-only interaction without descendants ends after the response, without that circuit. Purely Git publication is an exception: it does not materialize lifecycle records. SPEC/PRD remain active between child Runs and are delivered only through parent gates.
+
+Each Task attempt has exactly one responsible orchestrator. Gui is its last
+direct child, a sibling of executors, not a finalizer for every worker.
+The host persists the real decision before canonical Stop; it may relay an
+already-terminal Gui while the responsible Run is open, without requiring
+receipt polling. No decision means no approval. Direct standalone work uses an
+observed Task root with explicit direct authorization; no invented executor,
+and no waiver of Evidence or Gui. See [closure and recovery](.agents/zaip-aios/guides/16-lifecycle-e-reconciliacao.md).
+
+Proof depth is adaptive: a standalone \`lite\` Task requires at least one typed validation and one Evidence, normally one of each, but accepts legitimate additional proof. \`standard\` requires two or three validations according to \`verification_scope\` and at least one consolidated Evidence; \`critical\` requires three or more, independent review, and persisted risk signals determining additional controls. SPEC and PRD deliveries add a parent matrix, at least three validations and three Evidences, real integration, and independent review. New projects default to managed PRDs/SPECs and direct standalone Tasks; Codex or Claude execution requires an explicit request, isolated in worktrees, and limited by write scopes, commits, budgets, and typed gates. See [Adaptive assurance and opt-in autonomy](.agents/zaip-aios/guides/19-assurance-e-autonomia.md).
+
+## Autonomous engineering principles
+
+ZAIP-AIOS combines speed with explicit boundaries. Its principles keep code sustainable, distribute only necessary context, and require proof proportionate to risk.
+
+The schema default is \`execution.runtime: manual\` when the option is absent; this checkout uses \`managed\` in \`project.yaml\`. Configuration does not remove the need for an execution request or authorize publication. Always consult the project's effective file, not just the default described in the guide.
+
+- **Clean Architecture:** domain, application, adapters, and infrastructure remain separate; business rules do not depend on frameworks or external details, dependencies point inward, and composition roots connect concrete implementations at the boundaries.
+- **CQRS:** commands and queries follow explicit, independent flows; commands change state through appropriate use cases and ports, while queries have no side effects and return read models suited to reading.
+- **Modularization and code organization:** folders, files, modules, and components are structured by domain and responsibility, with explicit boundaries, high cohesion, and low coupling to simplify software navigation, maintenance, testing, and evolution.
+- **Bounded autonomy:** subagents work with DAGs, write scopes, sandbox, approvals, budgets, security rules, and gates proportionate to risk.
+- **Progressive context:** each agent receives only the Rules, Requirements, skills, and evidence relevant to its role, reducing noise, cost, and context loss.
+- **Proof-based completion:** tests, review, evals, checks, and Evidence must cover Acceptance Criteria before delivery.
+- **Recoverable history:** decisions, changes, attempts, failures, retries, repairs, and rollback remain linked, allowing work to be paused, resumed, and audited.
+- **Honest observability:** tokens, cost, time, coverage, and performance are measured by scope; missing telemetry remains explicit instead of creating fictitious precision.
+
+Intake captures once per observable turn and reuses valid focus in continuations; purely Git publication creates no lifecycle. Questions, feedback, and read-only analyses use an \`interaction\` Execution without an artificial Task or Change. Explicit creation/refinement of \`draft\` PRD/SPEC can persist those macros and the PreparedPlan in an interaction, without delivery. Outside that exception, an independent standalone edit materializes and starts a Task, Change, delivery, and Run before the first mutation; explicitly requested preparation may stop at Ready to Execute. A \`draft\` PRD occupies Definition and a \`draft\` SPEC occupies Planning; Tasks never occupy those columns.
+
+## Graph Engineering and Loop Engineering
+
+<img src=".agents/config/src/zaip-aios-obsidian.png" alt="ZAIP-AIOS in Obsidian" width="100%">
+
+**Graph Engineering** turns a complex delivery into a coordinated sequence of responsibilities. Instead of activating all 23 agents, orchestration selects the smallest set capable of planning, executing, reviewing, and proving the result according to dependencies, risk, and specialty.
+
+This autonomy remains governed: Dave coordinates, each executor receives only the necessary scope, Nanda performs independent review, additional specialists join when objective signals exist, and Gui closes the flow last. The result is a team tailored to the request without unnecessarily multiplying agents and cost.
+
+**Loop Engineering** uses the Task's frozen preset to reserve execution and replanning before the provider, record the result, and choose a corrected route. Balanced allows 1 + 9 executions and three plans: Sol/high → Astra/high → Astra/high; Essential never escalates to Astra, Persistent has no cap. Models never change silently within a Run. A standalone principal's manual preference does not require children to use the same configuration.
+
+### Summary flow
+
+A delivery flow with independent review is **intake → Dave → capability-selected executor → Nanda (review) → Gui (finalization)**. Review must satisfy the assurance profile; not every piece of work must expand to the same set of agents. All children are coordinated by orchestration; the sequence does not mean one worker calls the next.
+
+Complete scenarios are in the [flows and routing guide](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md), in stable text for GitHub.
+
+### Summary flows
+
+The lifecycle follows **Definition → Planning → Ready to Execute → Execution → Verification → Completed**. Blocked, Failed, and Canceled are alternative outcomes.
+
+Task, SPEC, and PRD retain independent flows; Conversation uses an interaction Execution and creates no artificial Task. A direct Task starts immediately, while a prepared one awaits execute.
+
+![Task, SPEC, and PRD lifecycles](.agents/zaip-aios/guides/assets/diagrams/lifecycles-task-spec-prd.png)
+
+Detailed flows for routing, intake, planning, rework, critical requests, model selection, the 23 agents, and Task orchestration are in the [flows and routing guide](.agents/zaip-aios/guides/22-fluxos-e-roteamento.md).
+
+## Technical and operational reference
+
+The following sections preserve the contracts needed for advanced installation, maintenance, auditing, security, and framework evolution. They complement the commercial overview without replacing the specialized guides linked throughout this document.
+
+## Current \`.agents\` structure
+
+**Consult the directory tree and technical responsibilities**
+
+\`\`\`text
+.agents/
+├── config/
+│   ├── project.yaml
+│   ├── framework.lock.yaml
+│   ├── agents/catalog.yaml
+│   └── profiles/clients.yaml
+├── dashboard/
+│   ├── zaip-dashboard-windows.exe
+│   ├── zaip-dashboard-linux.sh
+│   ├── zaip-dashboard-mac.command
+│   ├── apps/frontend/
+│   ├── modules/{operations,cost-monitor,traceability}/
+│   ├── packages/
+│   └── tests/e2e/
+├── design/
+│   ├── DESIGN.md
+│   ├── tokens.json
+│   ├── zaip-design.exe
+│   ├── apps/catalog/
+│   └── packages/
+├── branding/                         # business artifacts, created on demand
+├── marketing/                        # business artifacts, created on demand
+├── sales/                            # business artifacts, created on demand
+├── growth/                           # business artifacts, created on demand
+├── records/
+│   ├── prds/<year>/<month>/
+│   ├── specs/<year>/<month>/
+│   ├── changes/<year>/<month>/
+│   ├── tasks/<year>/<month>/
+│   ├── executions/<year>/<month>/
+│   ├── runs/<year>/<month>/
+│   ├── lifecycle/                    # manifests, indexes, and projections
+│   └── telemetry/<year>/<month>/writers/<writer-id>/{manifest.json,chunks/}
+├── rules/
+│   ├── core.md
+│   ├── workflow.md
+│   └── *.md                          # managed and local Rules, flat layout
+├── requirements/
+├── skills/
+├── tools/
+│   ├── catalog.yaml
+│   ├── {mcp,api}/
+│   ├── policies/
+│   ├── profiles/
+│   ├── runtime/
+│   └── servers/
+├── zaip-aios/
+│   ├── INDEX.md
+│   └── guides/
+├── runtime/
+│   └── bin/zaip.mjs                  # installed CLI and distribution metadata
+├── .env.example
+└── .gitignore
+.local/                              # at the workspace root; ignored by Git
+├── claims/                          # atomic lifecycle claims
+├── codex-telemetry-spool/v1/         # sanitized, private, recoverable capture
+└── sqlite/                          # local SQLite databases, separated by purpose
+    ├── zaip-aios-dashboard.sqlite    # Dashboard query model
+    └── <purpose>.sqlite              # example: other databases, created as needed
+\`\`\`
+
+The \`branding/\`, \`marketing/\`, \`sales/\`, and \`growth/\` folders are business-artifact areas created on demand. Their existence and content vary by project; there is no need to create empty folders.
+
+| Path | Responsibility |
+| --- | --- |
+| \`config/\` | Project configuration, client and agent profiles, capability maturity, and the integrity lock for managed files. |
+| \`dashboard/\` | Local operational Dashboard for Kanban, costs, time, tokens, and traceability; it queries rebuildable projections of canonical records, including SQLite. |
+| \`design/\` | ZAIP design system, visual tokens, component catalog, and local inspection launcher. |
+| \`branding/\` | Branding business artifacts, such as a Brandbook, brand platform, and identity governance; created on demand. |
+| \`marketing/\` | Business artifacts for marketing strategy, campaigns, content, and assets; created on demand. |
+| \`sales/\` | Business artifacts for sales methodology, qualification, playbooks, scripts, and handoffs; created on demand. |
+| \`growth/\` | Business artifacts for growth strategy, RevOps, and experiments; created on demand. |
+| \`records/\` | Git-native canonical source for PRDs, SPECs, Changes, Tasks, Executions, and Runs. \`records/lifecycle\` contains manifests, indexes, chunks, and summaries for discovery and pagination without scanning history. |
+| \`requirements/\` | Durable requirements and Acceptance Criteria for lifecycle, execution, costs, context, Dashboard, architecture, and design system. |
+| \`rules/\` | Canonical framework Rules and local project Rules, all directly in this directory. |
+| \`skills/\` | Reusable workflows that turn conversations into Requirements, Tasks, SPECs, and PRDs and guide execution, review, security, costs, context, and tools. |
+| \`tools/\` | MCP and API catalog, approval and secret policies, activation profiles, doctors, and auditable generated local servers. |
+| \`zaip-aios/\` | Operational handbook with a low-context-cost index and guides for installation, execution, review, agents, costs, security, and Codex integration. |
+| \`../.local/\` | Workspace-root directory for claims, writer ID, sanitized spool, and disposable SQLite; it stays outside Git. The Dashboard queries the projection, but canonical records remain in \`records/\`. |
+
+\`framework.lock.yaml\` is the mechanical reference for distribution-managed files, while \`project.yaml\` describes the consumer project. Rules present in the lock belong to the framework and can be updated by setup; Rules absent from it are local and must be preserved. Agents begin with \`rules/core.md\`, use canonical manifests in \`records/lifecycle\` for discovery, and open a historical record only after obtaining its explicit ID.
+
+The Dashboard's canonical code lives in \`.agents/dashboard\`, separate from product applications. It has only \`apps/frontend\`; its loopback server is in \`packages/local-runtime\`, not \`apps/backend\`. Its \`operations\`, \`cost-monitor\`, and \`traceability\` modules consume derived read models, using SQLite in the current runtime and in-memory compatibility paths. The mostly read-only API exposes controlled settings, priority, refresh, and explicit reconciliation actions; that does not authorize arbitrary changes. Windows, Linux, and macOS launchers live directly in \`.agents/dashboard\`; their presence in the template does not prove execution on all three environments.
+
+## Application architecture
+
+**Consult layout, dependencies, and code limits**
+
+When those surfaces exist, the canonical product-application layout is:
+
+\`\`\`text
+apps/
+├── frontend/       # Product UI and client composition root
+├── backend/        # APIs, workers, and server composition roots
+└── site/           # Landing page and public site, separately deployable
+modules/<area>/     # Business capabilities and their public contracts
+packages/<library>/ # Reusable technical libraries
+tests/e2e/          # Flows that cross applications
+\`\`\`
+
+Dependency direction is \`apps -> modules -> packages\`. This architecture describes only the consumer product's application code, not the ZAIP Dashboard or business domains. The \`branding/\`, \`marketing/\`, \`sales/\`, and \`growth/\` areas live in \`.agents\` as business-artifact folders created on demand; they are not application folders. \`apps/site\` never imports the Dashboard, does not read \`.agents\`, and does not depend on private backend implementation. Folders for absent surfaces do not need to be created empty. Unit tests stay with code; cross-application journeys live in \`tests/e2e\`.
+
+Source files with 401–800 lines generate a warning and files with 801 or more lines generate an error, except for explicit exceptions. The gate ignores generated code, distribution, vendor, data, and lockfiles. The list in [source-size-baseline.json](scripts/source-size-baseline.json) includes legacy packages and Dashboard code, with a frozen limit, owner, reason, and validity period; it does not authorize raising limits to hide growth.
+
+## Framework development
+
+**Consult contracts for maintainers and contributors**
+
+This section is for maintainers and contributors who change ZAIP-AIOS source. Consumers that only installed the framework in another repository do not need this routine to use Codex, create Tasks, SPECs, or PRDs, track the Dashboard, or run lifecycle normally.
+
+### Source repository and consumer project
+
+- **Source repository:** contains ZAIP-AIOS's official implementation, packages, Dashboard, Rules, Requirements, skills, tools, and distribution artifacts. Intentional changes must pass integrity, quality, test, and build gates.
+- **Consumer project:** receives a published framework version under \`.agents\`. \`framework.lock.yaml\` is updated only by transactional CLI installation or upgrade flows; a consumer project does not run \`sync:framework-lock\` to accept local changes.
+
+Consumer project settings remain in \`.agents/config/project.yaml\`; additional Rules are directly in \`.agents/rules/*.md\` and do not enter the lock. Distribution-managed files must not be changed and then added to the lock merely to silence drift.
+
+### Managed-file integrity
+
+\`framework.lock.yaml\` is a mechanical integrity manifest, not a dependency lockfile such as \`pnpm-lock.yaml\`. It records the paths and SHA-256 hashes of files belonging to the distribution, so accidental change, a missing file, or content different from the expected release can be detected. It does not store secrets, telemetry, or execution history.
+
+When a maintainer intentionally changes Rules, Requirements, skills, or another managed source file, they must review the change and then regenerate hashes:
+
+\`\`\`bash
+pnpm sync:framework-lock
+pnpm validate:framework-lock
+\`\`\`
+
+\`sync:framework-lock\` writes the new path-and-hash set. \`validate:framework-lock\` is read-only: it recalculates expected state and fails on drift. Do not run sync automatically to hide a discrepancy; first confirm that the change belongs to the framework and should be in the next distribution.
+
+### Local quality gates
+
+| Command | What it checks |
+| --- | --- |
+| \`pnpm validate:framework-lock\` | Confirms all managed files match locked paths and hashes. |
+| \`pnpm validate:skills\` | Validates skill structure, names, frontmatter, interfaces, links, resources, and security invariants. |
+| \`pnpm test:encoding\` | Detects invalid UTF-8, corrupted characters, *mojibake*, and other textual encoding issues. |
+| \`pnpm validate:source-size\` | Measures source files, applies limits and temporary exceptions, and flags components that need splitting into more cohesive modules. |
+| \`pnpm lint\` | Checks formatting, consistency, and static code rules. |
+| \`pnpm typecheck\` | Runs TypeScript type validation across workspace packages. |
+| \`pnpm test\` | Runs automated package tests through the workspace. |
+| \`pnpm build\` | Compiles and packages components and normalizes generated text. |
+
+A typical local validation, after updating the lock when necessary, is:
+
+\`\`\`bash
+pnpm validate:framework-lock
+pnpm validate:skills
+pnpm test:encoding
+pnpm validate:source-size
+pnpm lint
+pnpm typecheck
+pnpm test
+pnpm build
+\`\`\`
+
+Before integrating a relevant change or preparing a release, \`pnpm verify\` runs the complete repository pipeline, including additional tool, contract, generation, workspace, runtime-parity, and release-test gates. This pipeline only validates the lock; if a managed file was intentionally changed, run sync first. Use the pnpm version fixed in \`packageManager\` (\`corepack pnpm\` when available). For a bounded change, choose checks appropriate to its risk and diff; the list does not require repeating every test for each documentation edit. Release qualification uses the complete gates in [guide 26](.agents/zaip-aios/guides/26-qualidade-e-release.md) on the exact candidate. Do not conflate \`validate:github:prepared\`, local execution, push, and a green terminal CI.
+
+This checkout's manifests identify candidate \`3.0.0\` (product \`3.0\`). Candidate identity does not mean \`latest\` has been published or certify production. Release requires the exact revision, terminal CI, TGZ integrity, and a real artifact installation. Attempts and limitations remain in the Change evidence; local results and publication are distinct states.
+
+The detailed architecture is summarized in this README's [Application architecture](#application-architecture) section.
+
+## Security with permission profiles
+
+ZAIP-AIOS offers two permission profiles to balance convenience and containment. The profile selected by \`default_permissions\` sets the technical boundary the process can reach, while instructions, Rules, hooks, and skills still define what an agent is authorized to do.
+
+| Profile | Native filesystem on Windows | Command network | When to use |
+| --- | --- | --- | --- |
+| \`zaip-aios-full-access\` | Write access across \`C:\\\`, subject to ACLs and Windows-account privileges | Complete, with every allowed domain | Human default; still requires explicit authorization for external, destructive, publication, and elevation actions. |
+| \`zaip-aios-security\` | Write access only to this repository's physical root and descendants, including \`.git\`, \`.agents\`, and \`.codex\`; \`~/.ssh\` write access only for authorized Git/SSH flows | Limited to \`github.com\` | Opt in for least privilege; restart Codex after selecting it. |
+
+**Consult operation, risks, and defense in depth**
+
+The restricted profile uses a permissions table with the repository's **absolute physical root**, not \`:workspace\` or \`:workspace_roots\`. This keeps \`.agents\`, \`.codex\`, and \`.git\` writable on Windows without exposing the rest of \`C:\\\`. Its \`approval_policy = "never"\` does not authorize actions by itself: deploy, publication, remote mutations, and destructive actions still depend on an explicit request, instructions, Rules, hooks, and skills.
+
+### Risk of \`zaip-aios-full-access\`
+
+\`zaip-aios-full-access\` is a higher-risk profile. It can reach other repositories, user files, application and system directories, and any network destination allowed by the host. An incorrect command, malicious external content, or compromised dependency therefore has much greater potential impact. The profile grants no administrator privilege and still follows ACLs, corporate policies, and files in use, but those barriers do not make it equivalent to the restricted profile.
+
+\`zaip-aios-full-access\` is the human default and should be used only within the request's explicit authority. When an operation can be contained to the workspace, the user can select \`zaip-aios-security\` and completely restart Codex so the sandbox can materialize the selected profile. Do not change profiles merely to bypass a permission denial.
+
+### Deployment branch
+
+Every GitHub deployment reads \`.agents/config/project.yaml\`. Set the branch with:
+
+\`\`\`yaml
+deploy:
+  # Automated publication: validation environment.
+  branch: beta
+  # Production: human promotion only.
+  production_branch: main
+\`\`\`
+
+\`beta\` is the editable default: use another validation name, such as \`staging\` or \`homolog\`, when
+the project needs it. The database uses only \`beta\`, and production promotion requires a human
+action in GitHub. Frontend and backend follow their configured branch, including \`main\` when that
+choice is saved in configuration.
+
+\`deploy.frontend.branch\` and \`deploy.backend.branch\` are persisted authorization and may be
+\`main\`. Migrations use only \`deploy.database.branch: beta\`, with no production fallback.
+Installation does not create a beta environment or cost: verified beta GitHub/Supabase
+integration and informed cost confirmation are prerequisites, and \`beta -> main\` remains human.
+
+If the person explicitly declines hosted beta, use [manual mode](.agents/skills/zaip-skill-database-migrations/references/manual-mode.md): it exports SQL under \`db-migrations/\` for a human to run in the SQL Editor. The agent, pipeline, and startup never apply that file. Resume dependencies after recorded human success; a human report does not replace independent verification.
+
+Supabase queries use separate \`READ-ONLY-BETA\` and \`READ-ONLY-PROD\` contexts, each with its own
+\`project_ref\`, minimum read permissions, and a credential distinct from the pipeline credential.
+An absent reference, identical destinations, or unproven read-only capability means "not
+configured", with no fallback between environments. MCP snippets document configuration and do
+not create an authenticated connection. See the [deployment and access contract](.agents/skills/zaip-skill-backend/references/deployment-environments.md), which uses the [official Supabase MCP format](https://supabase.com/docs/guides/getting-started/mcp).
+
+### Defense in depth
+
+Both profiles retain compensating layers that reduce risk, but do not replace the native isolation offered by the restricted profile:
+
+- policy loading only in a trusted repository and explicit scope in \`AGENTS.md\`;
+- a \`PreToolUse\` hook checking known classes of escapes, secret references, destructive Git, force push, OS mutation, ACL, persistence, elevation, and destructive database actions, when the host actually runs it;
+- Codex \`forbidden\` rules, instructions, and skills that require explicit authority and limit each operation's scope;
+- GitHub deployment bounded by an explicit request, preflight, defined branch/remote, and scoped SSH identity;
+- protection against printing, logging, or committing tokens, private keys, credentials, and environment values;
+- Tasks, Changes, Executions, Runs, write scopes, threat model, rollback, negative tests, and independent review proportionate to risk;
+- subagents with bounded responsibilities and scopes, plus hashed adapters, framework lock, and regression gates;
+- remaining operating-system controls, such as ACLs, account privileges, and host policies.
+
+The \`PreToolUse\` security hook also remains active in the full-access profile without reducing its native permissions; it blocks destructive classes, secrets, publication, and elevation without authorization. Subagent lifecycle hooks remain active for defense in depth and attribution/telemetry. Browser, Computer Use, MCPs, and other integrations have their own surfaces and should be enabled and used only when necessary. For strong isolation against scope errors or malicious code, use the restricted profile and, when the risk warrants it, a dedicated account, VM, or external network and filesystem controls.
+
+The [complete ZAIP-AIOS permission-profile security guide](.agents/zaip-aios/guides/10-seguranca.md) documents the threat model, allow/deny matrix, layers, limitations, safe operation, rollout, rollback, and validation commands.
+
+## Optional automation and integrations
+
+### Hourly ready-queue scheduling
+
+In Codex Desktop, hourly ready-queue scheduling is configured by the \`$zaip-skill-instalar-agendamento\` skill in a single conversation in the local checkout. The skill uses native scheduled-task automation to create or update one standalone task with a stable name; it does not duplicate records and fails closed if \`automation_update\` is unavailable. The scheduled task explicitly calls \`$zaip-skill-executar-fila-pronta\` each hour.
+
+Each round processes the eligible snapshot sequentially: ready PRDs first, then independent ready SPECs, then standalone Tasks materialized in **Ready to Execute**. Descendant, active, blocked, failed, and terminal items stay out. In **Dashboard > Work (Kanban) > Ready to Execute**, priority is set top to bottom within the PRD/SPEC/Task tier and persists for the scheduler in \`.agents/dashboard/work-priority.json\`. Accessible ordering controls update that numbering, and items without a number go last through deterministic fallback. A local lock/lease prevents overlapping rounds.
+
+The repository versions this contract but does not install a clock in each clone. The scheduled task belongs to the machine/user who created it and depends on the machine being on, Codex Desktop running, and native automation being available; without them the skill fails closed and does not promise future execution.
+
+### Codex, official documentation, and browser
+
+\`.codex/config.toml\` is project configuration loaded by Codex only when the repository is trusted. In ZAIP-AIOS's current configuration, it guides \`AGENTS.md\` discovery and enables the official read-only OpenAI documentation MCP, allowing current information about Codex, models, APIs, SDKs, and MCP without relying solely on model memory. The installer also provides the discovery ZAIP skill, while Codex itself supplies stable resources such as shell, subagents, apps, hooks, and web search according to surface, account, and environment policy.
+
+This checkout's configuration contains enabled entries for browser plugins; that does not prove installation, availability, or effective host permission. When the in-app Browser is available it can support navigation, interaction, and real application capture, subject to sensitive-action permissions and confirmations. Do not presume the same tool on another Codex surface. For Playwright or another MCP, consult the manifest and policy under \`.agents/tools\` before enabling an implementation. A capture failure must be recorded as pending proof, never as approved visual validation.
+
+## Optional Obsidian traceability view
+
+The \`criar-pasta-obsidian\` skill generates a local, rebuildable projection in \`.local/obsidian/vault\` of relationships among PRDs, SPECs, Changes, Tasks, Executions, Runs, requirements, evidence, and tests. It does not make Obsidian a source of truth, duplicate full record bodies, or require the app to be installed to generate or validate the folder.
+
+At the repository root, generate or update the vault with:
+
+\`\`\`powershell
+node .agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs
+\`\`\`
+
+The [ZAIP traceability Obsidian guide](guide/CRIAR-PASTA-OBSIDIAN.md) documents application installation, opening the folder as a vault, generating a single Task, and updating the projection after \`git pull\`.
+`:n},...i]}function t(e,t){return e.match(/^#\s+(.+)$/m)?.[1]?.trim()??t.replace(/\.md$/i,``)}var n={"pt-BR":{eyebrow:`CONFIGURAÇÃO DO PROJETO`,title:`Preços e cotação`,description:`Valores em USD por 1 milhão de tokens. Ao salvar, o dashboard recalcula todos os valores com o catálogo vigente.`,back:`Voltar ao dashboard`,fxTitle:`Cotação utilizada no dashboard`,fxDescription:`Ao salvar, todos os valores em BRL são recalculados. Os valores em USD e a telemetria de tokens permanecem inalterados.`,fxLabel:`Cotação USD/BRL`,fxAriaLabel:`Cotação USD BRL`,catalog:`Catálogo de modelos`,pricesPerMillion:`Preços em USD por 1 milhão de tokens`,models:`modelos`,model:`Modelo`,provider:`Provider`,input:`Entrada (USD/1M)`,cache:`Cache (USD/1M)`,output:`Saída (USD/1M)`,reasoning:`Raciocínio (USD/1M)`,priorityInput:`Priority entrada (USD/1M)`,priorityCache:`Priority cache (USD/1M)`,priorityOutput:`Priority saída (USD/1M)`,priorityReasoning:`Priority raciocínio (USD/1M)`,contextLimit:`Limite contexto`,inputMultiplier:`Mult. entrada`,outputMultiplier:`Mult. saída`,noAliases:`sem aliases`,removeModel:`Remover modelo`,addModel:`Adicionar modelo`,cancel:`Cancelar`,saving:`Salvando…`,save:`Salvar e recalcular`,newModel:`novo-modelo`,manualOverride:`Substituição manual pelo dashboard`,editedNote:`Editado no dashboard`},"en-US":{eyebrow:`PROJECT SETTINGS`,title:`Pricing and exchange rate`,description:`Prices in USD per 1 million tokens. When saved, the dashboard recalculates all values using the current catalog.`,back:`Back to dashboard`,fxTitle:`Exchange rate used by the dashboard`,fxDescription:`When saved, all BRL values are recalculated. USD values and token telemetry remain unchanged.`,fxLabel:`USD/BRL exchange rate`,fxAriaLabel:`USD BRL exchange rate`,catalog:`Model catalog`,pricesPerMillion:`Prices in USD per 1 million tokens`,models:`models`,model:`Model`,provider:`Provider`,input:`Input (USD/1M)`,cache:`Cache (USD/1M)`,output:`Output (USD/1M)`,reasoning:`Reasoning (USD/1M)`,priorityInput:`Priority input (USD/1M)`,priorityCache:`Priority cache (USD/1M)`,priorityOutput:`Priority output (USD/1M)`,priorityReasoning:`Priority reasoning (USD/1M)`,contextLimit:`Context limit`,inputMultiplier:`Input multiplier`,outputMultiplier:`Output multiplier`,noAliases:`no aliases`,removeModel:`Remove model`,addModel:`Add model`,cancel:`Cancel`,saving:`Saving…`,save:`Save and recalculate`,newModel:`new-model`,manualOverride:`Dashboard manual override`,editedNote:`Edited in dashboard`}};export{n,e as t};