Skip to content
PETROVA

Future tasksets

Tasksets that are conceptually drafted but not yet opened. Each gets a one-paragraph sketch with explicit “decision needed before opening” criteria.

These are not commitments. Each requires a fresh dated decision doc before any work starts (per MR-7). The sketch below is enough to ground the decision when it’s needed.

Webhook receiver

Section titled “Webhook receiver”

What: A small service that receives GitHub webhooks for the governed repos and invokes verbs in response. Examples: PR opened on kahn-hq → fleet auto-diagnoses; CI failure on smo1-io → fleet proposes a fix.

Decision needed before opening:

  • Where does the receiver run? (Cloudflare Worker, Vercel function, long-running service.)
  • How is it authenticated? (Webhook secret, App installation token.)
  • What’s the failure mode if the receiver is down? (Webhooks queue, but eventually time out — fleets miss events. Acceptable?)

Trigger criteria: when polling-based fleet operation becomes demonstrably insufficient. Currently no fleet polls more often than 30 minutes, so latency isn’t pressing.

SQLite cache

Section titled “SQLite cache”

What: A local on-disk cache of cross-repo state for fast queries. Rebuilds from git/GitHub source on sync. Backs the dashboard and status verbs when the live walks become slow.

Decision needed before opening:

  • Cache schema (probably mirrors registry.yaml + per-repo decisions/findings/milestones).
  • Refresh trigger (on every CLI invocation, on a schedule, on receipt of a webhook).
  • Failure mode (stale cache vs no cache).

Trigger criteria: when petrova status or petrova dashboard takes more than 5 seconds at the repo count we then have. Currently sub-second at 2 repos.

Web UI dashboard

Section titled “Web UI dashboard”

What: A persistent rendered version of petrova dashboard. A browser-accessible URL showing fleet state without needing the CLI.

Decision needed before opening:

  • Auth boundary (is this internal-only behind airlock, or public?).
  • Static vs dynamic (rebuild on push vs live query).
  • Where does it live? (petrova.devarno.cloud/dashboard? Separate subdomain?)

Trigger criteria: when more than two people regularly want to see fleet state and not all of them have the CLI installed.

smo1-io registration

Section titled “smo1-io registration”

What: Add smo1-io as a governed repo. Currently in deferred-work because the local workspace dir isn’t a git repo with a known origin.

Decision needed before opening: confirm origin URL, decide profile (likely standard), enumerate the fleets that should have access.

Trigger criteria: when smo1-io is ready for cross-repo governance. No urgency.

Schema versioning + breaking-change policy

Section titled “Schema versioning + breaking-change policy”

What: A formal policy for when verb schemas can break (removing or retyping fields). Currently the schema fingerprint tracks versions, but there’s no published policy for major version bumps.

Decision needed before opening:

  • Rules for additive vs breaking changes.
  • Deprecation cycle length (one minor version? one major?).
  • How agent fleets discover that their pinned fingerprint is deprecated.

Trigger criteria: when the first non-additive schema change is needed. So far every change has been additive.

Registry CODEOWNERS

Section titled “Registry CODEOWNERS”

What: Add a CODEOWNERS file to petrova-hq requiring specific reviewers on registry.yaml edits. Currently the strict-profile + branch protection require some reviewer; this would require the operator specifically.

Decision needed before opening:

  • Who is the codeowner? (Single user? GitHub team?)
  • What happens when the codeowner is unavailable? (Emergency-bypass procedure.)

Trigger criteria: when registry edits start happening frequently enough that “any reviewer” isn’t a tight enough gate. Currently registry edits are rare (every onboarding event).

Cross-repo finding correlation

Section titled “Cross-repo finding correlation”

What: A read-only command that finds related findings across repos — e.g. petrova find-correlations --topic rls returns every RLS-related finding in any governed repo with date and status.

Decision needed before opening: a vocabulary for “topic” tags on findings. Either explicit (frontmatter topic: field) or inferred (TF-IDF over titles).

Trigger criteria: when an incident requires reconstructing related state across multiple repos and the dashboard isn’t sufficient.

Multi-tenant control plane

Section titled “Multi-tenant control plane”

What: Allow PETROVA to govern repos belonging to multiple organisations / customers, with isolation guarantees between them.

Decision needed before opening: significant. Auth model, registry scoping, billing, support model.

Trigger criteria: if PETROVA ever becomes a hosted product rather than internal infrastructure. Not currently a goal.

See also

Section titled “See also”