Skip to content

feat(automation): run fast-mlsirm commercial readiness every hour #713

Description

@seonghobae

Objective

Add a fixed-target hourly commercial-readiness loop for ContextualWisdomLab/fast-mlsirm:main that continuously prioritizes the pull-request queue and creates at most one bounded buyer-visible product-development slice only when the live queue is empty.

This complements, rather than duplicates:

  • .github#704: generic hourly review-feedback repair;
  • fast-mlsirm#410: repository-local cancellation of superseded CI and bounded review churn;
  • the existing read-only hourly PR-governance evidence workflow in fast-mlsirm.

Hourly orchestration contract

Run at an off-peak minute distinct from the generic repair scheduler. Every run must:

  1. validate the exact target repository and base branch;
  2. read the live open PR queue for main;
  3. dispatch the central review-feedback repair scheduler;
  4. dispatch current-head review/branch-update/direct-or-auto-merge processing;
  5. suppress product development whenever any PR is open, queue state is unknown, or another development worker/branch is active;
  6. when and only when the queue is definitely zero, dispatch one product-development worker;
  7. publish a deterministic summary of queue state and decisions.

Development worker contract

The worker may implement exactly one evidence-backed buyer-visible gap. It must:

  • clone the exact live main SHA and revalidate the queue before creating a branch;
  • refuse duplicate work when an unmerged autonomous branch or active worker exists;
  • inspect bounded repository guidance, open issues, recent merged PRs, product docs, commercial-readiness evidence, and relevant primary sources;
  • prioritize executable product gaps over speculative breadth;
  • use TDD and preserve 100% statement/branch coverage plus complete public docstrings;
  • keep numerical likelihood, gradient, Hessian, simulation, rotation, recovery, utility, and scoring arithmetic in Rust/PyO3 rather than Python;
  • preserve standalone package behavior and modular CWL/MSA integration;
  • use descriptive nonnumeric identifiers and two-or-more-word snake_case database object names;
  • update authoritative docs and docs/changelog.d; update the package version/release only in a separately reviewed release PR when truly release-ready;
  • run focused tests, full Python/Rust tests, formatting/lint, package smoke, security checks available locally, and diff checks;
  • push one bounded branch and open one draft PR; never write directly to main, merge, tag, publish, or release.

Hard safety bounds

  • fixed target: ContextualWisdomLab/fast-mlsirm, base main;
  • no branch/ref, repository, prompt, workflow, or credential field may be caller-selected;
  • no workflow_dispatch entrypoint for the privileged development worker;
  • trusted automation source checked out from the called workflow's immutable job.workflow_repository / job.workflow_sha;
  • least-privilege scoped target credential, fail closed when unavailable;
  • one worker at a time, one gap per run;
  • default maximum 12 changed files and 1,200 changed lines;
  • forbid edits to GitHub workflows, secrets, environment files, agent instructions, dependency manifests, lockfiles, and control-plane configuration from the product worker;
  • no shell/web/tool capability inside the coding agent beyond the checked-out target workspace and bounded trusted context;
  • issue and PR text treated as untrusted data, never executable instructions;
  • current-head independent review and required checks remain mandatory.

Product prioritization

Use an explicit decision order:

  1. correctness and scientific validity gaps;
  2. buyer-usable end-to-end verticals, especially rubric generation → untrusted candidate validation → pilot calibration → validity/fairness evidence;
  3. model comparison, recovery, scoreability, accessible exact-value reporting, interoperability, security/privacy, observability, packaging, and procurement evidence;
  4. measured Rust CPU/GPU performance and memory improvements;
  5. lower-impact maintainability only after buyer-facing gaps are exhausted.

Never claim that a finite candidate search proves a global optimum, correlation proves validity, schema conformance proves psychometric quality, or a test named “20b” proves commercial valuation.

Verification

  • TDD contract tests for fixed target, cadence, queue precedence, single-flight development, immutable workflow source, permission boundary, prohibited paths, file/line budgets, and draft-PR-only publication;
  • actionlint/shellcheck and Python tests;
  • 100% statement/branch coverage and docstrings for any helper scripts;
  • design and implementation plan under docs/superpowers;
  • no one-shot or self-modifying workflow used to patch the branch.

Acceptance

After merge, an hourly run autonomously dispatches review/fix/merge processing while PRs exist. When the queue is provably zero, exactly one bounded commercial product slice may be proposed as a normal draft PR. Every code change still requires same-head tests, security evidence, review, and repository-policy-compliant merge.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions