///|
pub fn playbook_rule_count() -> Int {
  96
}

///|
pub fn scenario_count() -> Int {
  64
}

///|
pub fn canary_playbook_markdown() -> String {
  (
    #|# CanaryRing Operator Playbook
    #|
    #|This built-in playbook documents practical canary rollout checks. It is kept
    #|inside the MoonBit package so CLI tools, CI jobs and teaching examples can
    #|render the same decision rules without depending on external files.
    #|
    #|## Identity and Ownership
    #|
    #|- CR-001: Keep the rollout owner, repository owner and Mooncakes namespace aligned.
    #|- CR-002: Attach one responsible maintainer to every production rollout.
    #|- CR-003: Record the package name before publishing any release candidate.
    #|- CR-004: Use one stable rollout salt per feature, not one salt per deploy.
    #|- CR-005: Never reuse a rejected project name when resubmitting a contest entry.
    #|- CR-006: Keep applicant identity outside public runtime output unless required.
    #|- CR-007: Do not mix credentials from another GitHub Desktop login.
    #|- CR-008: Keep the public repository URL and moon.mod repository URL consistent.
    #|
    #|## Segmentation
    #|
    #|- CR-009: Start with staff or internal users before external live traffic.
    #|- CR-010: Keep enterprise users out of the first live blast unless explicitly targeted.
    #|- CR-011: Exclude contractual VIP traffic from unproven checkout changes.
    #|- CR-012: Require a minimum client version when protocol behavior changes.
    #|- CR-013: Use region allowlists when legal or latency boundaries differ.
    #|- CR-014: Use region blocklists for data-residency experiments.
    #|- CR-015: Keep cohort assignment deterministic across restarts.
    #|- CR-016: Prefer tag-based selection for feature families.
    #|- CR-017: Avoid selecting users by mutable display names or email addresses.
    #|- CR-018: Keep traffic-unit weights visible when high-volume accounts exist.
    #|- CR-019: Report both user share and traffic share for every blast-radius estimate.
    #|- CR-020: Recheck segment count before moving from dry-run to live mode.
    #|
    #|## Phase Scheduling
    #|
    #|- CR-021: Shadow phases should run before dry-run phases.
    #|- CR-022: Dry-run phases should run before live phases.
    #|- CR-023: Avoid overlapping phase windows.
    #|- CR-024: Require manual approval for live phases at or above 50%.
    #|- CR-025: Keep phase duration long enough to collect minimum samples.
    #|- CR-026: Put a rollback or kill-switch phase in the plan before launch.
    #|- CR-027: Use monotonic exposure unless a rollback is intentional.
    #|- CR-028: Do not jump from 1% directly to 100% on stateful services.
    #|- CR-029: Keep dark-launch phases separate from customer-visible live phases.
    #|- CR-030: Record the target minute for every phase in UTC or a shared unit.
    #|- CR-031: Include pause windows for off-hours or support handoffs.
    #|- CR-032: Make phase names stable enough to appear in incident notes.
    #|
    #|## Metric Gates
    #|
    #|- CR-033: Require a minimum sample count before advancing.
    #|- CR-034: Track error rate as parts per million to avoid float drift.
    #|- CR-035: Track p95 latency in integer milliseconds.
    #|- CR-036: Track saturation in basis points.
    #|- CR-037: Treat synthetic check failures as hard rollback signals.
    #|- CR-038: Treat dependency failures as risk even when user errors are low.
    #|- CR-039: Compare current metrics with the previous window, not only with budget.
    #|- CR-040: Hold if latency jumps sharply even below the absolute ceiling.
    #|- CR-041: Roll back if error rate exceeds the hard budget.
    #|- CR-042: Hold if sample count is too low for confidence.
    #|- CR-043: Record the metric window used for every advance decision.
    #|- CR-044: Keep gate reasons human-readable for reviewer evidence.
    #|
    #|## Blast Radius
    #|
    #|- CR-045: Estimate exposed users for every active phase.
    #|- CR-046: Estimate exposed traffic units separately from users.
    #|- CR-047: Count distinct regions touched by a live rollout.
    #|- CR-048: Count distinct user tiers touched by a live rollout.
    #|- CR-049: Keep blast radius under the configured basis-point budget.
    #|- CR-050: Treat high-volume accounts as blast-radius multipliers.
    #|- CR-051: Prefer many low-volume users for early confidence.
    #|- CR-052: Avoid simultaneous region expansion and percentage expansion.
    #|- CR-053: Keep stateful writes below a stricter blast-radius threshold.
    #|- CR-054: Recompute blast radius after every segment change.
    #|- CR-055: Report risk score together with raw exposure counts.
    #|- CR-056: Block launch if the estimated blast radius exceeds budget.
    #|
    #|## Rollback Readiness
    #|
    #|- CR-057: Verify kill switch behavior before the first live phase.
    #|- CR-058: Keep rollback phase names explicit in reports.
    #|- CR-059: Predefine the metric reason that triggers rollback.
    #|- CR-060: Keep dependency rollback owners visible.
    #|- CR-061: Do not depend on GitHub Desktop login state for rollback evidence.
    #|- CR-062: Record whether rollback is config-only or requires redeploy.
    #|- CR-063: Keep migration rollbacks separate from feature flag rollbacks.
    #|- CR-064: Require manual approval before re-advancing after rollback.
    #|- CR-065: Capture the previous healthy metric window.
    #|- CR-066: Capture the first failing metric window.
    #|- CR-067: Include a customer-impact note for every rollback.
    #|- CR-068: Include a follow-up issue record after rollback.
    #|
    #|## Release Evidence
    #|
    #|- CR-069: Keep README usage aligned with the current package name.
    #|- CR-070: Keep examples runnable with moon run examples/basic.
    #|- CR-071: Keep CLI smoke runnable with moon run cmd/main.
    #|- CR-072: Keep moon check --deny-warn green.
    #|- CR-073: Keep moon test --deny-warn green.
    #|- CR-074: Keep moon fmt --check green.
    #|- CR-075: Publish only after dry-run succeeds.
    #|- CR-076: Confirm mooncakes.io latest_version after publishing.
    #|- CR-077: Confirm mooncakes.io build_status after publishing.
    #|- CR-078: Record the GitHub Actions run URL.
    #|- CR-079: Record the tag or release version.
    #|- CR-080: Keep LICENSE at repository root.
    #|
    #|## Contest Resubmission Safety
    #|
    #|- CR-081: Use a new name when the rejection reason is same-name overlap.
    #|- CR-082: Use a new repository link when the rejected repository name is itself implicated.
    #|- CR-083: Use a new Mooncakes package when the old package name is implicated.
    #|- CR-084: Explain the new project boundary in the proposal.
    #|- CR-085: Mention that the new project is not README/provenance proof tooling.
    #|- CR-086: Search GitHub for the new name before resubmission.
    #|- CR-087: Search Mooncakes for the new package name before resubmission.
    #|- CR-088: Avoid reusing public text that describes the rejected project.
    #|- CR-089: Remove stale rejected-project links from the new README.
    #|- CR-090: Remove stale rejected-project package names from moon.mod.
    #|- CR-091: Keep one applicant account and one Mooncakes namespace in all evidence.
    #|- CR-092: Do not include other contestants' repository names in submission materials.
    #|- CR-093: Keep the proposal concise and focused on the new technical route.
    #|- CR-094: Keep test output and CI output ready before resubmission.
    #|- CR-095: Keep Mooncakes publish evidence ready before final acceptance.
    #|- CR-096: If the contest asks for clarification, provide the new boundary and search evidence.
    #|
  )
}

///|
pub fn failure_scenario_catalog_markdown() -> String {
  (
    #|# CanaryRing Failure Scenario Catalog
    #|
    #|The scenarios below are domain fixtures for teaching, testing and checklist
    #|generation. They are intentionally expressed as plain text so downstream
    #|tools can embed them in review documents without network access.
    #|
    #|## Metric Failure Scenarios
    #|
    #|- S-001: Error rate exceeds hard budget during a 10% live phase.
    #|- S-002: Error rate doubles while still below absolute budget.
    #|- S-003: Latency p95 jumps by more than 200ms.
    #|- S-004: Saturation grows by more than 15 percentage points.
    #|- S-005: Synthetic checks fail during dry-run.
    #|- S-006: Dependency failures appear while customer errors are still low.
    #|- S-007: Sample count is too low to advance confidently.
    #|- S-008: Metrics are missing for the active phase.
    #|- S-009: Previous window was unhealthy and should not be used as baseline.
    #|- S-010: Latest metric timestamp is older than the phase end.
    #|- S-011: Metric window mixes shadow and live traffic.
    #|- S-012: Gate reason text is not retained.
    #|- S-013: Hold decision is ignored by a release script.
    #|- S-014: Rollback decision lacks a follow-up issue.
    #|- S-015: Metric budget uses percentage floats instead of basis points.
    #|- S-016: Synthetic checks are disabled for a payment path.
    #|
    #|## Segment Failure Scenarios
    #|
    #|- S-017: VIP contract accounts are included in the seed ring.
    #|- S-018: Region allowlist is empty by accident.
    #|- S-019: Region blocklist conflicts with allowlist.
    #|- S-020: Minimum client version is omitted for protocol changes.
    #|- S-021: Staff users are identified only by mutable tags.
    #|- S-022: Internal users receive live traffic instead of shadow traffic.
    #|- S-023: High-volume enterprise traffic dominates the first ring.
    #|- S-024: Free-tier users are used to validate enterprise-only behavior.
    #|- S-025: Bucket salt changes between deploys.
    #|- S-026: Cohort labels change after a restart.
    #|- S-027: Exclude tags are not checked case-insensitively.
    #|- S-028: User version comparison treats 2.10 as lower than 2.9.
    #|- S-029: Traffic-unit weighting is not included in blast radius.
    #|- S-030: Segment summary is missing from release evidence.
    #|- S-031: Staff ring and customer ring share a phase name.
    #|- S-032: Target segment selects zero users and hides lack of coverage.
    #|
    #|## Schedule Failure Scenarios
    #|
    #|- S-033: Two phase windows overlap.
    #|- S-034: Live phase starts before dry-run.
    #|- S-035: Shadow phase duration is zero.
    #|- S-036: Rollout jumps from 1% to 100%.
    #|- S-037: Large phase lacks manual approval.
    #|- S-038: Kill-switch phase is not represented in the plan.
    #|- S-039: Pause window is missing during support handoff.
    #|- S-040: Rollback plan requires redeploy but no redeploy owner is listed.
    #|- S-041: Phase names are not stable enough for audit evidence.
    #|- S-042: Phase schedule is written in local time with no shared unit.
    #|- S-043: Deployment is retried with a different salt.
    #|- S-044: Phase percent goes backward without rollback intent.
    #|- S-045: State migration and feature exposure are coupled.
    #|- S-046: Dark launch traffic is counted as live exposure.
    #|- S-047: Config change lands after metrics window closes.
    #|- S-048: Release tag is created before final check passes.
    #|
    #|## Evidence Failure Scenarios
    #|
    #|- S-049: Repository owner does not match submitted applicant account.
    #|- S-050: Mooncakes package namespace uses a different owner.
    #|- S-051: README still contains a stale rejected project name.
    #|- S-052: Proposal describes README proof instead of rollout simulation.
    #|- S-053: GitHub Desktop is logged into a different account.
    #|- S-054: CI is green for an old commit, not the submitted commit.
    #|- S-055: Mooncakes latest_version is not the version in moon.mod.
    #|- S-056: Mooncakes build_status is queued or failed at submission time.
    #|- S-057: License is missing from repository root.
    #|- S-058: Test record omits moon test --deny-warn output.
    #|- S-059: Release notes do not explain the new non-overlapping project boundary.
    #|- S-060: Public repo contains another contestant's phone or email.
    #|- S-061: Proposal has multiple GitHub links and does not identify the project.
    #|- S-062: Issue records are empty or mechanical.
    #|- S-063: Commit history has fewer than five meaningful contest-period commits.
    #|- S-064: Final resubmission uses a rejected-project package name.
    #|
  )
}

///|
pub fn resubmission_boundary_markdown() -> String {
  (
    #|# CanaryRing Resubmission Boundary
    #|
    #|CanaryRing is not a README checker, not an open-source provenance proof
    #|tool and not a submission-material auditor. Its core is a deterministic
    #|progressive delivery simulator:
    #|
    #|- stable hashing assigns users to canary buckets;
    #|- segment rules decide which users can enter a rollout;
    #|- rollout phases define shadow, dry-run, live and kill-switch windows;
    #|- risk budgets gate error rate, latency, saturation, dependency failures and synthetic checks;
    #|- blast-radius estimation counts users, traffic units, regions and tiers;
    #|- simulation reports decide whether a rollout can advance, hold or roll back.
    #|
    #|The project is useful for MoonBit ecosystem examples because it provides a
    #|pure deterministic library for a real SRE/product-engineering workflow.
    #|It has no network access and does not depend on GitHub or Mooncakes APIs at
    #|runtime, so it can run in tests, CI and teaching examples.
    #|
  )
}