Update to Frontier Infra

{
  "description": "Explain Frontier Infra's philosophy, architecture, projects, terminology, and patterns; choose and compose the right components for AI harness, governance, agent-readable web, attestation, discipline, or reliable-operations work.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 233
    }
  ],
  "name": "frontier-router",
  "skill_md_contents": "---\nname: frontier-router\ndescription: Explain Frontier Infra's philosophy, architecture, projects, terminology, and patterns; choose and compose the right components for AI harness, governance, agent-readable web, attestation, discipline, or reliable-operations work.\n---\n\n# Frontier Infra router\n\nUse this as the teaching and routing entry point. Read the references that match the question:\n\n- Philosophy or core claims: `../../references/philosophy.md`\n- Six-box and governance architecture: `../../references/system-architecture.md`\n- Reusable implementation patterns: `../../references/pattern-catalog.md`\n- Project selection and maturity: `../../references/project-map.md`\n- Adoption sequence: `../../references/adoption-journeys.md`\n\n## Workflow\n\n1. Resolve roles first. By default, the coding assistant is the developer and the user's product is the target application; do not cast the developer as one of the application's workers, verifiers, or governed subjects.\n2. Identify the target application's outcome, durable effects, failure history, trust roles, and required autonomy.\n3. Determine whether the user needs education, a design, an implementation, or an explicitly requested audit.\n4. Select the smallest components that close those failure modes; distinguish standards from deployments and experiments.\n5. State the intended target deployment shape: `machine`, `orchestrator`, or neither.\n6. Separate what the target application will instruct, instrument, enforce, receipt, and independently verify.\n7. Route implementation work to the focused skill and name the target artifacts and tests that will prove completion.\n\n## Composition guide\n\n- New harness architecture → `design-agent-harness`\n- Application implementation with published packages → `build-with-frontier-sdk`\n- Authority, mutation, reversibility, and override → `design-agent-governance`\n- One bounded work contract → `goal-contract`\n- Machine-shaped implementation → `machine-deployment`\n- Evidence-based audit → `machine-conformance` (scoring runs `npx -y @frontier-infra/audit`; the sibling `frontier-audit` plugin's `audit-and-attest` skill covers the score-and-attest flow end to end)\n- Model-driven domain pipeline → `conductor-pipeline`\n- Site ground truth → `avl-adoption`\n- Signed outcome evidence → `aar-attestation`\n- Repository operations → `maintainer-gates`\n\n## Boundaries\n\n- Apply Frontier semantics to the target system. Do not govern, contract, audit, or attest the interactive builder's process merely because the plugin is present.\n- Do not call an AAR's signature proof that the underlying claim is true; it proves who attested and what evidence was committed.\n- Do not call a model-driven controller a Dumb Driver. Use the orchestrator shape and its lower guarantee ceiling.\n- Do not call retries resilience without idempotency, budgets, quarantine, alerts, and kill/resume evidence.\n- Do not route secrets or private operational configuration into public plugin assets.\n"
}