AGENTS.md · git:20260929.198f9e4 · 2026-09-29 · sha256 2fa2fbe02eda42ef

AGENTS.md git:20260929.198f9e4A

Immutable. This exact content never changes and is served at /api/v1/blob/2fa2fbe02eda42ef.

# Contents

- `src/` – the CLI, page-capture runtime, strict data and protocol models, provider-plugin kernel, built-in providers, runtime assets, helpers, and colocated tests.
- `src/media/` – the finite-item media acquisition, archive, derivation, transcript, revision, verification, and cancellation runtime.
- `src/control/` – the menu-bar control service, approvals, account connections, and the shared-foundation menu adapter.
- `skills/ghostget/` – the single public Agent Skill and its focused operational references, including social publishing.
- `.agents/skills/` – reusable cross-repository KB and phased-execution workflows; product-specific Ghostget operations remain under `skills/ghostget/`.
- `kb/` – authored repository rationale, evidence, synthesis, and plans.
- `WRITING.md` and `STYLE.md` – internal and public prose contracts.
- `docs/` – provider-plugin authoring, trust-boundary guidance, the generated `assurance.md` assurance case, the nightly verification and quarterly claims-review procedure, and the public Puerto Rico rental-listings search contract.
- `scripts/` – standalone CLI, plugin lifecycle, clean-consumer package, and formal-verification checks.
- `website/` – the dependency-free, statically generated `ghostget.com` documentation and landing surface; it is excluded from the published package.
- `verification/` – the claims register, Quint models, Lean proofs, and checker pins behind `docs/assurance.md`; it is excluded from the published package.
- `.github/workflows/` – read-only Linux and macOS checks, a read-only nightly verification run outside `Required`, checks-gated immutable releases and release-only website production promotion, and Dependabot pull-request auto-merge.
- `README.md`, `CONTRIBUTING.md`, `SECURITY.md`, and `LICENSE` – usage, project policy, security reporting, and terms.
- `package.json`, `bunfig.toml`, `tsconfig.json`, and `bun.lock` – the standalone Bun package, isolated dependency layout, and frozen dependency graph.

# Guidelines

- Use Bun 1.3.14. Complete `Required` PR CI is the normal final source integration gate for executable and documentation changes, together with relevant focused local checks and independent impact and diff review. Record the repository, reviewed workflow, run and attempt, complete required job union, actual checked commit and tree, PR head, and current base. Revalidate immediately before conditional merge; head or base movement requires matching current-candidate CI. Preserve the executable phase-composition and disjoint source coverage contracts in `scripts/ci-pr-gate.test.ts`.
- CI covers the complete Linux aggregate and a selected macOS suite. For impacted native behavior outside that suite, run relevant focused macOS checks or add and pass an independently reviewed CI extension. Keep every explicit local, native, coupled-sequence, installation, live, package-release, provider-control, and production acceptance requirement. Diagnose known failures and retain their relevant reproduction and repair checks. Keep `bun run check` available as the complete local aggregate and use it when coverage or equivalence is uncertain or a required coupled or local reproduction needs the complete sequence. Independently review workflow, discovery, command, deadline, and platform changes against the prior required coverage; edited coverage assertions alone cannot certify a weakened workflow. An older candidate's receipt never qualifies a new integration. CI overrides the shared `cancel-in-progress: true` rule: it cancels only superseded pull-request runs and gives every `main` push its own commit-keyed group, because release admission needs a successful push run on the exact tagged commit. A pull-request `quint` shard skips Apalache only when its diff against the base misses `QUINT_APALACHE_SCOPE` in `scripts/verification-tools.ts`, and still typechecks, simulates, and replays every model; `main` push and nightly runs check every model with Apalache.
- Follow `WRITING.md` for internal prose and `STYLE.md` for public prose.
- Apply unreasonably robust programming when agent work is cheap. Model invalid states out of existence and pair readable regression examples with property tests for general laws.
- Deliver changes to `main` through a current-head pull request. Keep the stable `Required` CI job green, resolve every review thread, and serialize merges. Human approval stays optional while one regular maintainer would otherwise self-review. Never force-push or bypass the gate.
- Pin Hraness dependencies to reviewed immutable releases or full commits. Never replace them with sibling paths, Git submodules, or coordinated `main` assumptions.
- Extract a shared package only after two concrete consumers need the same stable interface. Keep shared packages product-neutral and keep consumer planning, policy, agent loops, and unrelated consumer UI outside Ghostget's menu-bar control surface.
- For UI work, consume shared design-kit or `@hraness/ui` primitives only at immutable versions; keep product composition in the owning product and keep `website/` dependency-free.
- Freeze shared interfaces before parallel lanes begin. Give public barrels, manifests, lockfiles, generated catalogs, and other convergence surfaces one owner while lanes edit disjoint paths.
- Keep mandatory rules in the closest `AGENTS.md`, current procedures in `docs/`, executable contracts in types and tests, and pull-based rationale, evidence, synthesis, and plans in `kb/`.
- Keep Ghostget a bring-your-own-agent CLI and TypeScript SDK with a menu-bar control surface for accounts, capabilities, permissions, interfaces, approvals, activity, and installation guidance. Do not add a bundled model, planning or tool loop, or agent runtime.
- Keep exactly one public Agent Skill at `skills/ghostget/`. Bundle product workflows as references and mark repository-maintenance skills under `.agents/skills/` internal.
- Keep `website/` informational: it may explain and document Ghostget, but must not grow an agent runtime, authenticated product surface, or browser-based substitute for the CLI and SDK.
- Keep the package root import side-effect-free. Importing `@hraness/ghostget` must not start the CLI, inspect local state, load built-in providers, or access the network.
- Expose bounded semantic provider operations. The separate public web gateway accepts only explicitly policy-admitted HTTPS retrieval URLs through its pinned transport and durable audit boundary. Never add caller-selected provider headers, cookies, selectors, scripts, shell commands, or arbitrary file access.
- Keep media acquisition to one authorized, accessible, finite, non-DRM item. Reject playlists, live streams, affirmative DRM, unsupported authentication, and access-control bypasses. Promote an item only after its inspectable archive, versioned manifest, and SHA-256 records pass complete verification.
- Treat source plugins as trusted in-process code. Treat portable child-process execution as ordinary-failure containment, not a hostile-code sandbox, and require an explicit trust decision for the exact verified bundle.
- Parse every foreign manifest, package, message, plan, receipt, response, and CLI value from `unknown`; reject extra fields, malformed bounds, ambiguous ownership, and drift.
- Keep installed support discoverable from the validated active catalog. Reject duplicate plugin, route, or operation ownership before a command can use it.
- Keep built-in durable contract hashes versioned and invariant across package layout and execution environment. Derive the exact current source/dependency closure automatically, snapshot it at registry startup, and revalidate it before and after lazy runtime load; do not maintain a manual closure allowlist or ask an end user, provider operator, or maintainer to approve source hashes. Portable-plugin identity must remain bound to its exact verified artifact.
- Bind every authenticated request to one exact account realm, provider target, transport, contract version, and implementation identity. Never silently switch transport.
- Keep mutations behind exact preview, confirmation, durable dispatch, and at-most-once evidence. Never retry or clear an indeterminate dispatch; reconcile it from separately obtained exact evidence.
- Keep raw authenticated traffic, cookies, tokens, profiles, private content, and local paths out of Git, tests, receipts, logs, and diagnostics.
- Pair concrete behavior with deterministic example tests. Add property tests for strict parsers, canonical encodings, identifiers, ordering, round trips, lifecycle transitions, and arbitrary input.
- Model consequential lifecycle workloads as bounded action and fault schedules over the production reducer or port. State safety and conditional progress laws with their environmental assumptions explicitly, keep clocks and randomness injected, and retain fast-check's seed and shrink path. Replay one exact property with `GHOSTGET_PROPERTY_SEED`, `GHOSTGET_PROPERTY_PATH`, and an anchored `--test-name-pattern`, then promote a minimized failure to a named regression. Reducer terminalization from supplied reconciliation evidence is not provider liveness.
- Keep the Bun runner timeout and concurrency policy in `package.json`; test bodies may own explicit product deadlines and elapsed assertions, but must not call `setDefaultTimeout` or pass per-test runner timeouts.
- Treat a checker timeout, an inconclusive or unparsed checker result, and a successful compile or typecheck alone as missing evidence; the `verification` job fails on each.
- Count a Quint model as conformance evidence only after an ITF trace replay test drives production code through its traces; until then it is design evidence. Pair every model with a seeded mutant or pre-fix variant that its checkers must find.
- Promote every recorded shrink or failing seed to a named example test.
- Pin Quint, Apalache, the JDK, elan, and Lean to exact versions, and admit every downloaded checker archive only at its pinned SHA-256.
- When you add or change a rule in an `AGENTS.md`, update its claims and rule digest in `verification/claims.json` in the same change. Give every claim its not-verified scope, and regenerate `docs/assurance.md`.
- Treat this repository as the complete project. Use only its public names, paths, commands, and dependencies in code, tests, documentation, and Git prose.
- Follow `docs/publishing.md` for canonical GitHub Releases and optional npm mirrors. Starting with v0.16.13, publish the exact five-file archive/packing-receipt/manifest/checksums/provenance contract independently of npm. Keep direct lightweight tags, exact owner/repository/workflow/run reauthorization, complete read-only source and isolated-install acceptance, a separate checkout-free OIDC attestation job, strict signed certificate/source/run/attempt verification, one bounded draft/upload/readback/publish writer, immutable Latest convergence, and current-main release-control closure. Preserve historical versions, tags, and assetless Releases. Immediately before tag dispatch, require administrator readback that immutable Releases are enabled; grant no Administration to workflows. The same tag Release run then publishes the identical canonical bytes to npm through the `npm-release` environment and OIDC trusted publishing: checkout-free, artifact by numeric ID, no `contentPolicy` declaration, clean npm configuration, exact archive hash, immutable canonical-release readback, idempotent exact-prior-publication recognition, and npm's monotonic default `latest` guard, followed by read-only registry identity and provenance admission. No dispatch, staged publish, token, or human step follows the tag push; an npm failure is rerun from the same run and never blocks canonical publication. The Release workflow must never read, create, or update `website-production`, receive the release App key, or wait for Vercel. Load the separate production-promotion workflow from reviewed main source `W`; prove release `C<=W<=M` for protected current main `M`, allowing only linear descendant movement after dispatch; bind its automatic `workflow_run` to Ghostget repository ID `1316443113` and Release workflow ID `323493609` plus the exact path, tag-push event, first attempt, success, head repository, tag, peeled immutable release SHA, and payload run ID. Manual recovery on that same main-origin workflow accepts only an untrusted stable-tag input and carries no upstream SHA, run ID, or attempt. Derive the authoritative run ID from the Release's sampled exact Actions receipt. In the initial verify job's authority resolution, read that Actions run exactly once and bind stable actor and triggering-actor numeric IDs and types, repository identities, workflow ID and path, tag-push event, source SHA, completion, success, and the applicable attempt; do not authorize on mutable logins or the run display name. The canonical download admits a receipt attempt whose conclusion is not success only through that attempt's complete bounded job inventory proving the four canonical jobs succeeded, because a later npm job cannot revoke a published immutable Release; when that attempt attested but did not publish, it also requires a strictly later completed attempt of the same run whose own complete inventory proves all four: the current attempt or, when that attempt did not publish, one of at most three exact intermediate attempts. Manual recovery requires a positive current attempt and admits an unsuccessful latest attempt only through that attempt's own bounded job inventory proving all four or, when that attempt did not publish, through the earlier receipt attempt that the Release body names, whose own bounded inventory must prove all four or, when that receipt attempt attested but did not publish, through one of at most three attempts strictly between it and the latest whose own attempt record binds the exact owner actors, repository, workflow ID and path, tag push, tag, SHA, and completion and whose own complete bounded inventory proves all four; a wider gap fails closed, and the mutable body only selects which inventories to read. The GitHub publisher downloads the attested artifact only by numeric artifact ID behind an exact-identity guard, so a failed-jobs rerun publishes the exact bytes and signed attempt its run already attested, never another run's or a later attempt's. Later strict by-tag Release reads revalidate the sampled exact source receipt, tag, Latest projection, Release ID and publication time, source SHA, and workflow source using the carried run ID without rereading Actions. Carry that run ID through exact `wrench-provider-baseline-v4` and `wrench-provider-promotion-v3` receipts and every later authority, promotion, and outcome check. Grant `actions: read` only to the initial verify job. Record the complete bounded Vercel Production baseline before any key-environment wait. An already-exact ref must take a separate read-only path with no environment, App variable, private key, token mint, or Git push.
- Treat the Release display title, Actions workflow-run display name, actor logins, and receipt body as mutable presentation or control-plane data. Validate the sampled exact source receipt on every accepted Release read; stable numeric identities and types, the protected tag, and immutable Release coordinates remain authority.
- Keep the `npm-release` environment fail closed: administrator bypass disabled, no reviewers, no secrets, sole protection rule `branch_policy`, and the single custom deployment policy `tag` `v*` with no branch admitted. Only `publish_npm` may reference it or mint an npm OIDC token; the npm trusted publisher names `release.yml` and this environment. Any drift blocks npm publication; do not weaken the environment to recover a run.
- A required fast-forward must enter `production-ref-writer-key` with `deployment: false`, no required deployment reviewers or wait timer, `prevent_self_review=false`, and no administrator bypass; admit it automatically after the existing immutable release, exact workflow-source, and provider-baseline checks pass, then revalidate source and immutable release authority before credentials and mutation; and authenticate one private Hraness App. The App registration and every minted token must close to exactly `metadata:read`, `contents:write`, and `workflows:write`, with no Administration or other permission. Workflows write is required because an admitted fast-forward may introduce reviewed `.github/workflows` changes. Runtime must request and validate a token narrowed to Ghostget repository ID `1316443113`; privileged setup must separately enumerate the installation-wide selected-repository set and prove it contains only Ghostget before key admission. The writer's retained admission proof is workflow run `33691443614`: an ordinary `P` to `C` update was denied, the dedicated App performed the only leased fast-forward, the stale lease was rejected, and token revocation converged to two stable authorization denials. Retain persistent canary `refs/heads/website-production-canary` at exact `C=0bf88a064233635e0c5485c61f9c533974a7dca4`; never reset, delete, or repurpose it. Keep the production lifecycle and App-only update rules mirrored on that ref, keep the single-use canary source removed, and retain the exact run, ref, ruleset, rule-suite, denial, and token-revocation evidence. Keep the production helper hard-bound to `website-production`. Never broaden permissions silently. Scrub every `WRENCH_RELEASE_APP_*` value from read-only `gh` children. Fetch only the exact verified tag through the private askpass token, peel it locally to the independently verified SHA without executing tagged code, and then push that admitted object through the same ephemeral credential boundary with explicit `--force-with-lease=refs/heads/website-production:<expected-old>`. Mask the installation token around that exact fetch and one leased push, then send exactly one empty-204 revocation request and require two stable authorization denials from the exact Ghostget installation-repository endpoint inside the reviewed ten-slot, 30-second monotonic operational window before the exact ref post-read. Require canonical GitHub `Date` headers strictly before the minted `expires_at` on that DELETE 204 and every accepted 200 or 401. In the sanitized receipt, `propagationObserved=false` means the first two probes were the stable 401 pair with no observed 200; `propagationObserved=true` means at least one exact 200 preceded the final two stable 401s. Bind that exact bounded object as `releaseAppRevocation` in every advanced `wrench-provider-promotion-v3` receipt, and bind `null` on the separate no-write `already-exact` path. Treat the window as a fail-closed ceiling, not a GitHub propagation SLA; reject a denial that returns to authorization, nonconvergence, indeterminate timing or transport, and any malformed or unexpected response. Never retry the action, retain concurrent operation and revocation failures, and cap the App path at fourteen REST requests. Require bounded read-only jobs to bracket promotion with authenticated GitHub server time, fingerprint the complete current state and `latestStatus` of at most 500 Production deployments, and exhaustively audit only the pinned candidate's REST status history. Reject any retained failure, error, or inactive candidate status even after success. Bind the REST deployment's lowercase commit `.ref` and `.sha` to the verified release while GraphQL reports a null `ref` and the same `commitOid`. Keep 20 observation slots at absolute minute offsets zero through 19 inside one injected monotonic 20-minute `[start, deadline)` interval and a separate 30-minute read-only job. Charge API latency to that window without sliding later slots, and never start a provider read at the deadline. Bind one exact successful Vercel Production deployment plus stable terminal tag, Release, Latest, workflow source, ref, inventory, status, and canonical-host readbacks before promotion succeeds. A verified Production build emits one exact seven-key `/.well-known/wrench-release.json` after its site build, binding the verifier-proven local HEAD and release tag to the strict unique Vercel deployment URL. The provider baseline reads it twice; only exact v0.16.5 may begin from 404. Outcome requires that deployment URL to equal the pinned status URLs, permits only baseline-to-target movement, and finishes with two stable apex marker/health snapshots plus one exact no-follow `www` 308 in each snapshot. Preview and local builds emit no marker. Do not make correctness depend on bypassing Vercel's static cache, and do not make the global receipt depend on previous deployment statuses that GitHub deletes after 90 days; GitHub preserves the current status on the deployment.
- Before every stable tag push, a signed-in administrator must freshly prove immutable Releases enabled and read back all four active repository tag rulesets. They form two split pairs: one pair targets only `refs/tags/v*`, and the other targets only `refs/tags/desktop-v*-macos-arm64`. In each pair, the creation-only ruleset must have exact rule `creation` and sole always-bypass User `894119`; it must never authorize update or deletion. The immutable ruleset must have no bypass actors and exact deletion plus update rules; it must never authorize creation. Any other active tag ruleset is drift. Current rulesets `22311815` / `Release tag creation` and `19989752` / `Immutable version tags` for stable tags, and `22960902` / `Desktop release tag creation` and `22960911` / `Immutable desktop release tags` for desktop tags, are retained evidence; their split semantics, not their IDs or names, are authority. The same readback confirms branch rulesets `21832074` and `21887484`, described below. Never give GitHub Actions or another Integration a release-tag bypass. The Release workflow must not receive Administration permission or call ruleset endpoints. The only manual branch-create exception is the documented one-time Vercel bootstrap at the exact current immutable Latest Release commit. After it, a missing production branch is a hard failure. Live ruleset `21832074` supplies no-bypass creation, deletion, and non-fast-forward protection to the production and persistent canary refs. Live ruleset `21887484` supplies the sole update restriction and exact App `4783991` `Integration` bypass with `bypass_mode=always`; no other actor may update either ref. Incident freeze ruleset `22182820` was removed by captured numeric ID during the audited v0.16.4 production promotion and is historical, not a live control. Checked-in `CODEOWNERS` supplies ownership and notification only. Protect-main has no bypass actors and retains pull-request admission plus the exact Required CI check. Keep its approval minimum at zero and `require_code_owner_review=false` until a second eligible independent code owner exists. Keep Vercel's Production Branch on `website-production`; keep exact project `prj_TZbDZ38ABPan158IqnczgsuTu6Ue`, team `team_UAd1iD2XogJlbFg4h14mRaPM`, GitHub repository ID `1316443113`, `link.productionBranch=website-production`, `autoExposeSystemEnvs=true`, and persistent `autoAssignCustomDomains=true`. False may stage without moving the canonical domains and is never a release-time toggle. Require exact setting-only before/after readback for first enablement and the full persistent project/target/domain preflight thereafter. Ambiguity is readback-only; recovery never blindly reruns, rewrites the ref, or individually aliases a candidate. `main` and pull requests are preview sources, never production website sources.
- An owner release request authorizes the agent to perform the fresh administrator readbacks and create and push the exact admitted lightweight tag through the existing owner User `894119` session, without a second conversational approval. Verify that signed-in identity and its administrator access to this repository before use. Push the tag only after the tagged commit's own `main` push `CI` run has completed successfully, because Release admission reads that run once and never waits. Preserve all source, tag, immutable-release, and delivery gates. Missing access, control drift, and provider or runtime denials still block the affected action. This authorization grants no workflow or Integration identity additional permissions or tag bypass.
- The retained proof is evidence, not standing mutation authority. At setup, after a control-plane configuration or workflow-authority change, and during drift recovery, fresh administrator readback must reconfirm the permanent rulesets and target refs; the sole App `4783991` `Integration` bypass; the exact App permission set; installation `158077029` selects only Ghostget repository ID `1316443113`; and the main-only, automatically admitted `production-ref-writer-key` environment with no required deployment reviewers or wait timer, no administrator bypass, `prevent_self_review=false`, exactly four App identity variables and the one private-key secret. Control changes must include fresh readback evidence before activation. Routine promotions use the existing per-run immutable artifact and source checks, exact App and token permission and repository checks, live GitHub ref enforcement, lease, revocation, and provider/public readback; they do not require a separate administrator census or reviewer. Any detected drift leaves production unchanged until those controls are requalified. The audited v0.16.4 removal of incident freeze `22182820` does not authorize changing either permanent rule or silently weakening a future incident freeze.

- Bind every Release run at entry to a protected tag-push event and embedded sender owned by User `894119` in public Ghostget repository ID `1316443113`. Before the sole write-capable job checks out source, use only `actions:read` to bind the exact current attempt—including both `actor` and `triggering_actor`—to Release workflow ID `323493609`, its exact path, the verified direct tag object, and current-main ancestry; reject delegated reruns.

- Before `publish_npm` sets up npm or mints OIDC, bind its current attempt—including both `actor` and `triggering_actor`—to owner User `894119`, Release workflow ID `323493609`, the protected tag ref, the verified source SHA, and public Ghostget repository ID `1316443113`; delegated reruns must fail closed. Download the attested canonical artifact only by numeric artifact ID and bind all five files to the verify hashes and bundle digest. Independently parse the packed manifest inside that checkout-free job and permit no top-level `tag` plus only `publishConfig.access=public` and the canonical npm registry—reject scoped registries, proxies, credentials, and all other publication settings. Admit only an absent registry version newer than public `latest`, or the same version already public with the exact canonical integrity (skip without a second write); never overwrite a published version. Scrub ambient tag variables and project, user, and global npm configuration; prove pinned npm's clean default tag is `latest`; re-read the immutable canonical Release immediately before `npm publish` without `--tag`. Require the exact public registry package and its npm provenance to match the canonical archive in `admit_npm` before advertising registry availability; canonical publication is independent of npm latest.

- The `@hraness/ghostget` npm coordinate is published as ordinary software by owner decision on 2026-09-10: the package carries no `contentPolicy` declaration and no `DISCLOSURE` file, matching the other Hraness listings. Ghostget's page capture, media archiving, encrypted reads, and typed provider operations behind exact preview and explicit confirmation are agent tooling, not security-research or obfuscation software. The first publication of the new coordinate was one owner-authenticated publish of the exact canonical archive; every later version publishes automatically from the tag Release workflow's trusted publisher with provenance, unified with the other Hraness packages. Do not add a content-policy declaration or a staged-publish requirement back without an owner decision.
- A matching archive hash is insufficient release authority. Before GitHub mutation, require successful cryptographic verification of the canonical attestation bundle for all four subjects, exact signed certificate repository/source/workflow/run/attempt identity, and safe archive/receipt inspection. Promotion CI independently verifies the published canonical archive and original successful Release run. The Vercel build checks immutable metadata, bot/source receipt, exact five descriptors, manifest/archive digests, local HEAD/tag, and Latest; it trusts authenticated canonical workflow admission and does not claim local Sigstore verification. Historical assetless Releases retain their prior npm manifest admission.

- Public copy (websites, READMEs, docs, package and GitHub descriptions, CLI help, `llms.txt`, generated pages) follows `STYLE.md`, synced from hraness/.github. Text a model writes for publication also follows `GENERATION_STYLE.md`.
- The delivery vocabulary in this file (admission, qualification, custody, receipt, bounded, lane, gate, surface, projection) is internal. Translate it into what the reader gets.
- Take one-line product and sibling descriptions from the portfolio registry and versions from the release record. Tests pin facts, not prose.
- Run `bun run check:copy` before handoff when the repository has it.

- Essays and blog posts follow the essay addendum in `GENERATION_STYLE.md` and `ARTICLE_COPY.md` in `@hraness/design-kit`. The byline is “Hraness”, every post shows the provenance note naming its recorded reviewer, and no AI-drafted post is credited to a person unless that person rewrites and adopts it.
- Take product names, one-line descriptions, addresses, status labels, and relations from the portfolio facts in `@hraness/design-kit`. Render versions from the release record (`package.json`, a published-release file), never typed by hand.
- Write a “How X uses Y” post only for a registered relation that has a description. Change the relation and its post in the same change. Link between products only along registered relations, and between a technique post and product posts about the same technique.
- Every post has a review record: reader job, non-obvious answer, sources with the date checked, owner, reviewer identity, reviewer type (`ai` or `human`), a score out of 12, and a `reassessOn` date 28 to 56 days after review. The reviewer is independent of the run or person that drafted the post. An AI reviewer is recorded and shown as AI; `humanReview` stays null unless a person reviewed the post.
- A new post starts out of search indexes, sitemaps, and feeds. It becomes indexable only when its review record is complete, scores at least 9 of 12 with no zero score, and the page shows the provenance note.
- When a product is renamed or a relation changes, update the post bodies that mention it in the same change.

- Treat the user's request to change this repository as standing authorization for routine task-owned commits, pushes, pull requests, merges, releases, deployments, and production verification after the gates applicable to that action pass. Do not ask for duplicate confirmation. Build confidence through relevant automated checks, bounded diagnostics, and independent review, not another human approval. Passing checks does not expand task scope or authority.
- Prefer agentic service provisioning for new infrastructure. Check Vercel Marketplace for a native product that can provision the required resource first; use Stripe Projects as a supported alternative when it better covers the service or the Marketplace route only connects an existing account. Verify the current catalog, account, region, plan, recurring cost and resource capabilities before selecting a route. Prefer supported provider CLIs or APIs over browser-only setup when neither catalog fits, and explain the concrete exception. Reuse existing owner-controlled resources where appropriate; this preference alone does not authorize migrations, duplicate accounts, paid upgrades or wider access. Continue setup already authorized by the task and budget without duplicate confirmation. Keep provider credentials and generated environment files private, complete required interactive authentication, and verify deployment, persistence and recovery separately from successful provisioning.
- Separate artifact admission from live qualification and operational activation. Use applicable automated source, security, package/install, and provenance evidence for artifact admission; live provider qualification is not a universal publication prerequisite. Preserve explicit live acceptance criteria and require relevant live evidence for claims that depend on it. If publication or an artifact's install, upgrade, or default-use path activates risky unqualified behavior, keep that behavior guarded or disabled, or obtain bounded relevant evidence before shipping or activation.
- Use the repository's documented delivery workflow and preserve the identity, target, capacity, migration, and recovery guards applicable to operational activation. Replace an obsolete gate through a reviewed source and policy change with corresponding tests, never an ad hoc skip. Preserve every runtime-enforced approval, access control, branch protection, environment rule, safety policy, and required final gate. Ask for user input only when delivery needs a material product decision, missing credentials or authority, unavoidable interactive authentication, an irreversibly destructive action outside task scope, or resolution of a failure that cannot be handled safely and autonomously.
- Preserve production and user data throughout delivery. Inspect the exact account, environment, deployment, and data target before writes. For data changes, inspect a dry run or equivalent migration plan and validate the recovery path before any effect that could lose or corrupt data. Prefer additive, backward-compatible migrations and bounded batches. Record mutation intent, use idempotency or conditional writes, and reconcile uncertain results before retrying. Verify deployed identity, health, and relevant data invariants after delivery. Routine delivery never authorizes resetting, truncating, dropping, or overwriting user data; stop the unsafe operation if preservation or recovery cannot be established.
- Prefer short-lived repository workload identities such as OIDC trusted publishing, GitHub Apps, and narrowly scoped machine identities. Use unattended stable publication and production promotion when supported by the provider and repository. Establish supported machine authority once and verify it with a non-publishing preflight where available; routine releases should not require recurring interactive authentication or conversational approval. Releases and deployments run without a human in the loop: do not add required reviewers, manual approval environments, or wait timers to release or deployment paths, and remove any you find through a reviewed change. Keep account two-factor authentication, and do not add long-lived personal tokens.
- Main delivery is unattended. Open the pull request and enable auto-merge in the same breath (`gh pr merge --auto --squash <number>`), then move on; the required `Required` check is the reviewer. Until a repository's ruleset requires a check, `--auto` merges immediately, so wait for green checks there before merging. Never request a human reviewer or add required approvals, code owners, required conversation resolution, merge queues, manual-approval environments, or wait timers, and remove any you find with `scripts/apply-delivery-policy.py` from hraness/.github rather than by hand. Required checks run on the pull request head and are not re-required after main moves, so auto-merge never stalls behind another merge; main reruns the same gate after integration, and a red main is fixed forward by the next change. Repositories without CI use direct pushes to main.
- Preserve useful reasoning fan-out, but avoid unnecessary checkout fan-out. Prefer subagents in the current task for bounded research, review, diagnosis, and focused checks when they can safely share one working tree; create a separate task or worktree only for independently deliverable divergent edits, an isolated verification tree, or a different execution environment.
- Give each expensive focused validation command and external wait one owner. The integration owner reviews that evidence and runs the repository-required aggregate or final gate once after convergence. Reuse evidence only for the exact Git tree, command, lockfiles, toolchain, relevant environment, and validity period, and never to skip a required final integration, merge, release, deployment, or production-verification gate.
- On Hraness development machines, use the installed host scheduler for heavyweight top-level commands when available. Keep ordinary work in the compute lane; give authenticated browser/dev-server/Chromium work one `browser-auth` owner and Mac-only validation one `mac-native` owner.
- When a CI or policy gate scans complete Git history, check out the exact governed SHA and fetch only the fully qualified governed refs before scanning. Preserve the complete-history gate and reject unexpected refs instead of importing unrelated concurrent heads.
- At closeout, record applicable branch, PR, check, merge, release, deployment, and production evidence. Archive only conclusively finished tasks, never from silence alone, and reclaim only freshly revalidated clean merged worktrees through the guarded exact-path flow.

- CI exists to admit a change in minutes, not to perform a ceremony. Every workflow declares `concurrency: { group: <name>-${{ github.ref }}, cancel-in-progress: true }` (release and deploy workflows set `cancel-in-progress: false`), a `timeout-minutes` on every job, and `permissions: contents: read` at the top with job-level widening only where needed.
- One job named `Required` closes every check workflow: `if: always()`, `needs:` every blocking job, and a single step that fails unless each `needs.<job>.result == 'success'`, or `skipped` because the change filter below reported its inputs unchanged. Branch policy requires only `Required` (plus a provider's own automated admission status when the product depends on it). Never make CodeQL, scheduled, or advisory jobs required.
- Cache by lockfile hash and restore before install: `Swatinem/rust-cache@v2` (with `save-if: ${{ github.ref == 'refs/heads/main' }}`) for Cargo, `oven-sh/setup-bun@v2` plus `actions/cache` on `~/.bun/install/cache` for Bun, `actions/setup-node` cache or `actions/cache` for npm/pnpm, `actions/setup-python` with `cache: pip` or `astral-sh/setup-uv` with cache for Python. Playwright browsers are cached under `~/.cache/ms-playwright` keyed by the Playwright version.
- Rust: install the pinned toolchain with `dtolnay/rust-toolchain` (`rustup toolchain install` at most once per job, `--profile minimal`), set `CARGO_INCREMENTAL: 0`, `CARGO_TERM_COLOR: always`, `CARGO_NET_RETRY: 10`, `RUSTFLAGS: -D warnings` and `RUST_BACKTRACE: short` at workflow level, use `cargo nextest` or one `cargo test --workspace --locked` after a shared `cargo build --all-targets --locked`, run `clippy` and `fmt` once on Linux only, install tools with `taiki-e/install-action` or `cargo-binstall` instead of `cargo install`, and build release binaries in one job whose artifact every later job reuses. Never build the same crate twice in one workflow.
- Run the matrix Linux-first. A macOS or Windows job exists only when the product ships a native surface for that OS, runs the OS-specific tests only, and is never the only place a generic check runs. Split long serial script lists into parallel jobs that share one build artifact instead of one job that runs for twenty minutes.
- Skip work that cannot change the result inside the workflow: a change-detection job runs `dorny/paths-filter@v4` (it needs job permission `pull-requests: read`, and `predicate-quantifier: some-with-excludes` needs v4), and jobs whose inputs did not change skip through job-level `if:`. Never put `paths`, `paths-ignore`, or `branches-ignore` on the `pull_request` trigger of the workflow that produces `Required`: a skipped workflow never reports `Required`, and the pull request can never merge. Every `uses:` pins a major tag or a SHA with a version comment, and Dependabot keeps `github-actions` current weekly with auto-merge.
- Measure before and after: a CI change records the previous and new median wall time of the slowest workflow in its pull request body. Regressions that add more than a minute to `Required` are reverted forward the same day.

- GitHub Release pages follow `RELEASES.md` in hraness/.github: the title is the registry product name and the tag, and the body is a summary, `## Changes`, `## Install`, `## Verify`, then the repository's identity record as a trailing HTML comment.
- The summary and changes come from the version's section of `CHANGELOG.md` in the tagged commit. Write that section in the version bump pull request. The release workflow copies it, generates Install and Verify from the release record, fails when the section is missing or empty, and never uses GitHub's generated notes.

- `costs.json` at the repository root is the checked registry of every product data surface: store, kind (`authoritative` | `derived` | `telemetry` | `served`), retention class (`ephemeral` | `ttl:<ISO-8601>` | `account` | `tombstone` | `persistent`), owner module, and budget. A new table, bucket, stream, dynamic route, blob, or provider meter fails `check:cost-surfaces` until it registers.
- Bound every input before storage or provider I/O: request bytes, row counts, page sizes, batch sizes, retry counts, and event payloads. Unbounded input is a contract violation.
- No writes on read paths. Reads may cache; they never mutate. Hand a read path a read capability with no writer members, such as `AuthIncarnationReader`, not an environment that reaches writers. The menu-bar snapshot and its account and permission listings take no admission and create no state; account saves, the control-service startup backfill, and admitted execution paths create auth incarnations. The auth checks of a cache read, a live-read publication, and an omni materialization read the incarnation through `AuthIncarnationReader`, so a missing incarnation reads as changed and nothing is created. Read-path preparation (capability and omni reads, cache-only invocations, and control-plane inspection), confirmation preparation, and the operation-permission account identity bind the current incarnation the same way: they read it through `AuthIncarnationReader`, fail closed when it is missing, and create none. Only explicit invocation preparation, an admitted execution path, may create a missing incarnation. `invoke --projection-identity-only` is the SDK's identity preflight for a live invoke, so it is execution preparation and remains an admitted creator; `invoke --cache-only` is a read path and creates none. Two bounded exemptions (D14). First, a read-projection cache read may create and release its own admission claim and remove a claim whose recorded owner is proven dead, because it must exclude a concurrent projection transition; the claim is coordination state with no data. Second, a cache read may create the projection encryption key and its store-key marker when they are absent, because a miss returns the query key that this encryption key derives; each is created at most once per state home and holds no user data. The exemptions cover nothing else.
- `repair-signals` is a bounded derived diagnostic cache, not execution authority or an audit log. Keep failed-invocation signals free of account identifiers, inputs, private content, and raw errors. Catalog/check/cache-only/identity-only inspection must not record demand. Repair handoffs never authorize capture, retry, activation, or publication; changed contracts remain unverified candidates.
- Derived state is rebuildable and lives in the cheapest tier that can serve it. Only authoritative state pays for transactional storage.
- Every mutation carries an idempotency key; a retried write never double-charges storage, quota, or provider spend.
- Analytics and metering events come from a checked allowlist with a byte ceiling per event.
- Content bytes live in the content store; the control plane keeps references and metadata only.
- Run `bun run check:cost-surfaces` before handoff whenever a data surface changes.

- Prefer the globally installed `algal-*` skills for bounded git state, diffs, repository survey/search, test and release gates, CI polling, and web fetches instead of repeated raw tool output.
- At session start, if the `algal` skill is unavailable, install the current skill pack for Claude Code, Codex, and Devin for Terminal with `bunx skills add 0thernet/algal-skills --global --agent claude-code codex devin --skill '*' --copy --yes`.
- Confirm installation with `bunx skills list --global`. If Bun or network access is unavailable, continue with repository-native tools instead of blocking delivery.
- Treat ALGAL receipts as execution evidence, not provider attestation, and preserve the repository's normal verification and release gates.