Live dashboard

Factory Status

This is the live dashboard behind Explore's Dark Factory claim: current maturity, AI usage, repo automation seams, release evidence, and recent factory activity.

Want the narrative version first? Read Dark Factory. Want the product story? Read About Explore.

Generated: 2026-04-20 08:24 UTC

Factory Maturity

Closer to Level 5

Level 4.5: Autonomous delivery with a few true Level 5 gaps left

This factory now behaves like a disciplined Level 4 system with strong Level 5 traits: local-first CI, agent-owned PR and release flow, and recorded deploy plus smoke evidence.

4.5 / 5.0

  1. Level 1

    AI-assisted coding

    The repo already treats AI as a normal implementation tool rather than an occasional helper.

  2. Level 2

    Recorded agent pairing

    Prompts, run logs, acceptance criteria, and verification artifacts make each slice inspectable.

  3. Level 3

    Agent-owned implementation

    Agents own branch setup, implementation, local verification, and PR preparation.

  4. Level 4

    Agent-owned delivery

    The factory expects agents to carry work through CI, merge, release, deploy, smoke, and cleanup.

  5. Level 5

    Outcome-autonomous dark factory

    The remaining gap is outcome confidence: richer scenario proof and stronger trust that the system can ship routine work with minimal human governance.

What is already in place

  • Full local CI before PR creation The fast feedback loop now happens locally, so remote CI is mostly confirmation instead of first discovery.
  • Remote CI confirmation and same-PR fixes The factory watches GitHub checks, fixes failures in the same PR, and waits for a final green state.
  • Agent-owned release path Normal dark-factory work is documented as continuing through merge, deploy, smoke, and recorded evidence.
  • Visible execution artifacts Prompts, run logs, timing summaries, and AI usage reporting make the operating model legible.

What is still missing for Level 5

  • Scenario-first outcome validation Most proof still comes from repo tests and smoke checks instead of a richer scenario harness that validates end-to-end user outcomes.
  • Higher-confidence external-system simulation A true Level 5 setup usually has stronger test doubles or digital-twin style validation for risky dependency behavior.
  • Default trust in autonomous shipping The process is close, but it still needs more operational history before routine shipping feels completely black-box safe.

AI Economics

Production shows placeholder AI economics because the live app server does not store Codex session logs.

Model: gpt-5.4 (placeholder)

Reasoning effort: medium (placeholder)

Estimated token usage: 123,456 (placeholder values shown because production does not store Codex session logs)

Estimated cost: $1.23 (placeholder)

Deploys & Smoke

Latest release evidence: 2026-04-19_2083-release-develop-to-main-live.md (2026-04-19)

Smoke evidence: present in 2026-04-17_2064-release-develop-to-main-live.md

Runbook: docs/ops/smoke-check.md

Command: bin/host_factory smoke

Promotion Policy

Active default lane: Governance. Promotion horizon: Ready for merge. Active run horizon: Ready for merge. Execution mode: Single slice.

Governed software delivery and promotion through PR-based trust boundaries.

Current stage: Request received. Stop stage: Ready for merge.

What advances automatically: Request received -> Local green -> PR created -> Remote CI green -> Ready for merge.

What still needs human approval by default: merge_approval.

What advances next: Approve and merge the PR after required checks are green.

Feature-program mode: available for larger objectives; bounded slices merge first, then the final selected horizon runs.

No tracked feature-program manifests yet.

  • Governance: Governed software delivery and promotion through PR-based trust boundaries.
  • Startup operating model: Governed cross-functional operating flow from assessment through live proof.
  • deployed: Continue through the configured deploy path, then stop before smoke/live-proof confirmation.
  • local_only: Stop after local validation and recorded evidence before PR or deployment promotion.
  • merged: Continue through merge and cleanup, then stop before any release or deploy path.
  • pr_created: Create the PR and stop before remote CI waiting or ready-for-merge progression.
  • ready_for_merge: Wait for remote CI, mark the PR ready, and stop at the merge gate by default.
  • smoked: Continue through smoke and final proof/evidence capture when the host supports it.
  • Feature program: A larger objective is tracked in a feature-program manifest, delivered as bounded slices, and only promotes to its final horizon after the feature completion gate is met.
  • Single slice: One bounded change follows its lane until the selected promotion horizon.

Active default profile: auto_pr_manual_merge. Human gate: merge_approval. Stop point: wait_for_human_merge_approval.

Default governed story: Request received -> Local green -> PR created -> Remote CI green -> Ready for merge.

Prompt/job overrides: allowed.

Start the governed path with: bin/factory_promote continue --title "<slice title>" --prompt-path <prompt> --run-log-path <run-log>

Default Path

  • Request received: This is where a new request enters the factory.
  • Local green: This stage is inside the active automatic path for the selected lane and horizon.
  • PR created: This stage is inside the active automatic path for the selected lane and horizon.
  • Remote CI green: This stage is inside the active automatic path for the selected lane and horizon.
  • Ready for merge: This stage is inside the active automatic path for the selected lane and horizon.

Later Stages

  • merged: auto_or_manual This later stage is modeled explicitly and becomes active when the horizon or execution mode extends further.
  • deployed: command_or_manual This later stage is modeled explicitly and becomes active when the horizon or execution mode extends further.
  • smoked: command_or_manual This later stage is modeled explicitly and becomes active when the horizon or execution mode extends further.

Default next human action: Approve and merge the PR after required checks are green.

Deploy command when policy allows it: gh workflow run deploy_production.yml --ref main

Smoke command when policy allows it: bin/host_factory smoke

  • pr_creation: auto_create
  • remote_ci: wait
  • ready: mark_ready
  • merge: manual
  • cleanup: auto
  • release: manual
  • deploy: manual
  • smoke: manual
  • evidence: record
  • auto_pr_auto_merge: Create the PR, wait for CI, mark ready, and merge automatically when green.
  • auto_pr_manual_merge: Create the PR after local green, wait for remote CI, then stop for human merge approval.
  • full_promotion: Create the PR, wait for CI, merge automatically, then continue into configured release, deploy, and smoke hooks.
  • local_only: Stop after local verification and recorded evidence.
  • post_merge_cleanup_only: Run only the configured local cleanup flow after a merge has already happened.
  • routine_web_release: Create or reuse the develop-to-main release PR, wait for CI, merge automatically, then let the routine web release command watch the deploy workflow verdict.

Repo Automation

Provider: github. Current mode: manual. Portability impact: optional layer.

Credential requirement: not required for the current lane.

Supported auth sources: gh_cli

CI readiness source: host-test, factory-proof-test, lint, scan_js, scan_ruby

Current ci_status result: unavailable via unavailable. Readiness: unavailable.

No supported GitHub credential source is currently available for ci_status reads.

PR association view: unavailable via unavailable.

No supported GitHub credential source is currently available for PR association reads.

Merge-readiness view: unavailable via unavailable.

Merge readiness is unavailable because the underlying ci_status result could not be read live.

This proof is read-only and narrow. It can show current-ref PR association plus required-check-based merge readiness, but it does not infer approvals, branch protection, merge queue state, or merge policy.

Repository: johnnybutler7/johnnybutler-com

Required checks summary: 0 passed, 0 pending, 0 failed, 0 missing, 0 manual, 5 unavailable.

  • host-test: unavailable via config
  • factory-proof-test: unavailable via config
  • lint: unavailable via config
  • scan_js: unavailable via config
  • scan_ruby: unavailable via config
  • PR creation and updates: governed_cli
  • CI status reads: github_cli (uses configured required checks)
  • PR association reads: github_cli
  • Merge readiness evaluation: ci_status (uses configured required checks)
  • Evidence and status posting: not_enabled

Sections

Harness

Validation harness docs and checks.

1 markdown files

Latest: README.md

Updated: date unavailable

View details (coming soon)

Prompts

Recorded job prompts with scope and acceptance criteria.

889 markdown files

Latest: 2083-release-develop-to-main-live.md

Updated: 2026-04-19

View details (coming soon)

Runs

Execution logs with verification outputs.

892 markdown files

Latest: 2026-04-19_2083-release-develop-to-main-live.md

Updated: 2026-04-19

View details (coming soon)

Scenarios

Acceptance scenarios (holdout excluded from this page).

21 markdown files

Latest: 869-job-request-new-integration-option.md

Updated: date unavailable

View details (coming soon)

Recent Activity

  • prompts: 2083-release-develop-to-main-live.md (2026-04-19)
  • runs: 2026-04-19_2083-release-develop-to-main-live.md (2026-04-19)
  • runs: 2026-04-19_2082-agent-setup-loom-embed.md (2026-04-19)
  • runs: 2026-04-19_2080-google-oauth-redirect-uri.md (2026-04-19)
  • prompts: 2076-governance-linkedin-series-plan.md (2026-04-18)