Skip to content

R9: complete historical target harnesses - #12

Merged
EmergentMonk merged 170 commits into
mainfrom
r9/e3-e4-targets
Sep 27, 2026
Merged

EmergentMonk merged 170 commits into
mainfrom
r9/e3-e4-targets

Conversation

@EmergentMonk

@EmergentMonk EmergentMonk commented Sep 27, 2026 •

Copy link
Copy Markdown
Member

Purpose

Complete the remaining R9 — Retro portability expansion implementation machinery after merged PR #11.

This PR does not claim Windows 9x, Classic Mac OS, AmigaOS or physical-hardware support merely because harnesses exist. It implements the source-bound E3/E4 evidence path required before those claims can be made.

Implemented

  • immutable RETRO-v2.md human authority;
  • machine/retro-v2.json;
  • machine/project-v12.json;
  • common source-bound guest WEB1 proof;
  • strict E3 receipt validator;
  • strict physical E4 receipt validator;
  • Windows 9x 32-bit Win32 payload build;
  • Windows 9x QEMU full-system injection/execution harness;
  • Classic Mac m68k payload build using Retro68;
  • Classic Mac PowerPC payload build using Retro68;
  • Classic Mac q800/mac99 full-system harnesses with HFS Startup Items injection;
  • Amiga m68k payload build using Amiga GCC;
  • Amiga FS-UAE full-system HDF/Kickstart harness;
  • SHA-256-gated manual workflows for all proprietary guest/ROM media;
  • physical-hardware E4 receipt template and retention guidance;
  • PR CI for frozen-source preservation, receipt validation, harness syntax and target payload builds.

Frozen boundary

Merged R9-v1 source is frozen at:

7d260e0671c5d089b25d6075ab1b66fb0886c99e

No R1-R8 API or WEB1 semantic is modified.

Guest proof

Every E3 guest payload embeds the exact Git source revision and target profile and must locally reproduce:

  • document FNV-1a64: 75be6cc92698ac1a
  • source FNV-1a64: 5cf7c63a1fa3d9b4
  • history: 2
  • bookmarks: 1
  • fetches: 4
  • downloads: 1
  • target-specific pointer width / endian

The host refuses to mint an E3 JSON receipt if any field differs.

Evidence boundary

Harness-ready is not support.

The following remain unclaimed until a passing target-specific receipt is actually retained:

  • windows9x-x86 E3;
  • classic-mac-m68k E3;
  • classic-mac-powerpc E3;
  • amiga-m68k E3;
  • physical E4 targets.

No proprietary Windows, Mac OS, AmigaOS/Workbench, Kickstart or Macintosh ROM media is stored or redistributed by RIVET.

Review boundary

Review only actionable R9 target-build, full-system harness, receipt-integrity, media-validation, source-binding, portability, or evidence-claim defects.

R10 transport relay is deliberately not included.

Summary by Sourcery

Complete the R9 historical-target evidence machinery with source-bound payloads, full-system harnesses, strict E3/E4 validation, and CI safeguards while keeping platform-support claims gated on retained target evidence.

New Features:

  • Add source-bound full-system E3 harnesses for Windows 9x, Classic Mac m68k and PowerPC, and Amiga m68k targets using operator-supplied, SHA-256-pinned guest media.
  • Add strict physical-hardware E4 receipt validation and evidence-retention guidance.

Bug Fixes:

  • Prevent invalid or ambiguous retro evidence from being accepted by enforcing source, runtime OS, CPU, proof, startup, digest, timeout, and receipt-type constraints.

Enhancements:

  • Introduce the Retro v2 human and machine-readable evidence contracts while preserving the frozen R1-R9-v1 source and WEB1 semantics.
  • Add target-specific guest proofs with runtime OS witnesses and portability safeguards, including a CRT-free Windows 9x payload.
  • Clarify that buildable harnesses do not constitute platform-support claims without retained passing target receipts.

Build:

  • Add Windows 9x, Classic Mac, and Amiga target payload build scripts and toolchain metadata.

CI:

  • Add CI coverage for frozen-source preservation, receipt and input validation, harness syntax, guest-proof freshness, and all historical target payload builds.

Documentation:

  • Document Retro v2 E3/E4 evidence contracts, media handling, receipt retention, and remaining evidence gates in the README, roadmap, repository guidance, and static site.

Tests:

  • Add comprehensive E3/E4 receipt, guest-proof freshness, workflow-input routing, and negative-regression self-tests.

Executed CI evidence

Exact review head: 319fd30f4a1a597bd9f71d1f25f431b1a4db3e62.

The complete R1–R9 workflow matrix is green on this head.

The new R9 Historical Target Harnesses workflow is also fully green:

  • frozen R9-v1 source gate: passed;
  • machine JSON validation: passed;
  • E3/E4 receipt self-test: passed;
  • Python/shell harness syntax: passed;
  • Windows 9x payload build: passed;
  • Classic Mac m68k payload build: passed;
  • Classic Mac PowerPC payload build: passed;
  • Amiga m68k payload build: passed.

Observed target payload evidence:

  • Windows payload: PE32 executable (console) Intel 80386, for MS Windows;
  • Classic Mac payloads: both Retro68 m68k and PowerPC build steps completed successfully using ghcr.io/autc04/retro68 (observed pulled image digest sha256:cb4d58ea194f81e12e8c9b0735be4be9e65e7ccba58e00490d488af63c3cc33f);
  • Amiga payload: AmigaOS loadseg()ble executable/binary, built with amigadev/m68k-amigaos-gcc (observed pulled image digest sha256:b18080e6ffca8f793e0f539536a9138e9d2a548ca1a301c7483f43ee15fedfed).

These are payload/build observations only. They are not E3 OS-family execution claims.

Remaining evidence gate

After this PR, the R9 implementation/harness layer is complete, but platform-support claims remain intentionally gated by external media/hardware:

  • Windows 9x requires a passing media-pinned E3 workflow receipt;
  • Classic Mac m68k requires a passing HFS + ROM-pinned E3 receipt;
  • Classic Mac PowerPC requires a passing HFS-pinned E3 receipt;
  • Amiga m68k requires a passing HDF + Kickstart-pinned E3 receipt;
  • physical systems require a validated rivet.retro-e4-receipt/v1 with hashed attachments.

No such receipt is fabricated or implied by this PR.

Codex hardening pass

The current review head also fixes the follow-up evidence/security findings:

  • Windows 9x E3 receipts now require an independent captured VER identity in the Windows 4.00/4.10/4.90 family; XP 5.1 and missing-VER cases are retained negative regressions.
  • Workflow-dispatch strings are routed only through validated environment variables; a CI guard rejects ${{ inputs.* }} inside R9 run: shell source.
  • E4 browser proofs bind target, source revision, pointer width and endian in addition to the frozen WEB1 hashes/counters.
  • E4 manufacturer/model/CPU fields reject empty, whitespace-only and control-character identities.
  • Windows 9x launches the PE32 proof through WINSTART.BAT, not DOS-phase AUTOEXEC.BAT, and records startup_stage=winstart.
  • The retro guest proof's large workspace uses static storage, and the Amiga harness additionally provisions a 131072-byte shell stack before execution.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on the exact review head.

Freshness and receipt-type hardening

The exact review head additionally enforces:

  • stale guest proof deletion before full-system execution on Windows 9x, Classic Mac, and Amiga;
  • host extraction-path cleanup before each run;
  • Windows proof invocation prepended ahead of existing WINSTART contents;
  • exact WINSTART startup-stage evidence required by the E3 receipt validator;
  • non-empty bounded emulator identity in E3 receipts;
  • non-empty bounded E4 attachment names;
  • exact JSON integer types for E4 memory/pointer/count fields, rejecting booleans;
  • retained regressions for stale-proof ordering, whitespace-only emulator identity, empty attachment names, and boolean numeric fields.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

ROM and template hardening

The exact review head additionally enforces:

  • amiga-m68k and classic-mac-m68k cannot mint E3 evidence without an explicit 64-hex ROM SHA-256;
  • separate negative regressions cover both ROM-backed profiles;
  • the distributed E4 physical receipt example is intentionally non-evidence (result: template-not-evidence);
  • CI directly validates that the untouched example fails, while a separately populated E4 fixture still passes.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

OS identity hardening

The exact review head additionally enforces:

  • windows9x-x86 accepts only consumer Windows identities whose product name matches the 4.xx family: Windows 95/4.00, Windows 98/4.10, or Windows Me/Millennium/4.90; Windows NT 4.00 is rejected;
  • physical E4 receipts require software_environment.os_name, software_environment.os_version, and software_environment.api;
  • E4 OS/API identity must be compatible with the selected target profile, so the same hardware/proof cannot be relabeled across operating systems;
  • the human and machine Retro v2 contracts and physical receipt template carry the same requirement.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Historical-runtime compatibility hardening

The exact review head additionally enforces:

  • Windows 9x proof exit handling uses COMMAND.COM-compatible IF ERRORLEVEL branching and never %ERRORLEVEL%;
  • E4 OS versions are validated against target-specific historical version envelopes;
  • E4 CPU identities are validated against the selected target architecture family;
  • the Amiga full-system workflow installs Xvfb/xauth and runs FS-UAE via xvfb-run -a on GitHub-hosted Ubuntu;
  • retained regressions cover the modern-Windows-version contradiction, x86-on-m68k CPU contradiction, COMMAND.COM batch semantics, and Xvfb wrapper presence.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Windows 95 runtime and timeout hardening

The exact review head additionally enforces:

  • Windows 9x E4 CPU identity uses explicit x86 model/architecture tokens rather than bare vendor names; a valid 80486DX2 receipt passes while Itanium is rejected;
  • the Windows 95-floor guest proof is a freestanding PE using Kernel32 only, with local C memory primitives and a custom mainCRTStartup;
  • CI audits the PE import table and rejects MSVCRT/UCRT/API-set CRT imports; the exact-head build reports PE32 Intel 80386 with only KERNEL32.dll;
  • Windows, Classic Mac, and Amiga harnesses accept GNU timeout statuses 0/124/137 only to proceed to fresh guest-proof extraction; the timeout status itself is never evidence.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Mixed CPU identity hardening

  • E4 physical CPU identity now uses full-string matching rather than substring search;
  • mixed host/emulator prose such as Intel Core i9-14900K running a 68040 emulator is rejected;
  • target-compatible physical identities such as 68040, Motorola 68040, and Intel 80486DX2 remain valid;
  • RETRO-v2 and machine/retro-v2.json carry the same whole-identity rule.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Provenance sentinel and guest-exit hardening

  • E4 rejects the Git null source OID and the all-zero SHA-256 placeholder digest;
  • Windows E3 requires exactly one proof_exit=0 marker inside the receipt validator itself;
  • canonical m68k CPU identities such as MC68040 / Motorola MC68040 are accepted while full-string architecture matching remains enforced;
  • retained regressions cover all four cases.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Single-proof and PowerPC identity hardening

  • E3 rejects the Git null source OID;
  • E3 proof files must contain exactly one rivet-r9-guest line, so contradictory duplicate proof lines cannot be ignored;
  • Classic Mac PowerPC E4 evidence accepts canonical PowerPC 604e identities while retaining full-string physical CPU matching;
  • retained regressions cover all three cases.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Ambiguous evidence and compatibility hardening

  • Classic Mac PowerPC E4 evidence now requires System/Classic Mac OS 7.1.2 or later in the 7.x line; pre-PowerPC releases such as 7.0 are rejected;
  • Windows E3 evidence permits exactly one Windows ... [Version ...] identity line, preventing contradictory Windows 98 + XP proofs;
  • Windows x86 E4 accepts canonical AMD Am386/Am486 identities such as AMD Am486DX4;
  • E3 guest-media, payload and ROM SHA-256 values reject the all-zero placeholder digest;
  • every rivet-r9-guest:-prefixed line counts toward the single-proof rule, including malformed duplicates.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

E4 provenance and Windows drive hardening

  • E4 attachment names reject shipped REPLACE-WITH-* sentinels;
  • E4 source revisions must resolve to real commit objects in the RIVET checkout;
  • Windows 9x full-system execution takes an explicit validated DOS drive instead of assuming C:;
  • WINSTART and RUN-R9 use the selected drive, and the CRT-free guest proof writes RECEIPT.TXT relative to its working directory;
  • CI guards prevent reintroducing hard-coded guest-drive paths and verify DOS-drive normalization.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

E3 source and runtime OS witness hardening

  • E3 source revisions must resolve to real commit objects in the RIVET checkout;
  • the frozen-source gate inspects the complete baseline-to-HEAD changed-path set, so newly added frozen-surface files cannot bypass preservation;
  • Classic Mac E3 payloads query the running guest with Gestalt(gestaltSystemVersion, ...) and retain a Toolbox/system-version witness;
  • Amiga E3 payloads retain live ExecBase and dos.library versions from the running guest;
  • non-Windows E3 receipt minting requires exactly one target-compatible runtime OS identity, preventing Linux/m68k or CPU-only evidence from becoming an OS-family claim.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

HFS operand and hardware sentinel hardening

  • E4 hardware manufacturer/model/CPU values reject shipped REPLACE-WITH-* sentinels;
  • Classic Mac hfsutils operations use explicit relative HFS operands for payload copy, stale-proof deletion, and receipt extraction;
  • retained regressions cover REPLACE-WITH-EXACT-MODEL and the required :RIVETR9 / :RIVET-R9-RECEIPT.TXT forms.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Windows CPU floor and receipt parser hardening

  • Windows 9x E4 evidence enforces product-specific CPU generation floors: Windows 95 >= 386, Windows 98 >= 486, Windows Me >= Pentium-class;
  • failed E3 generation clears any existing requested receipt before validation and publishes successful JSON atomically through a temporary file;
  • E4 JSON parsing rejects duplicate object keys recursively at every nesting level;
  • retained regressions cover Me-on-386 rejection, stale E3 output cleanup, and duplicate top-level/nested JSON fields.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Windows identity, PowerPC 7400, memory floor, and v2 authority freeze

  • Windows E3 counts every Windows ... [Version ...] occurrence across the proof, including multiple identities concatenated on one physical line;
  • Classic Mac PowerPC E4 accepts canonical PowerPC 7400 / G4 identity;
  • Windows E4 enforces product-specific RAM floors: Windows 95 >= 4 MiB, Windows 98 >= 16 MiB, Windows Me >= 32 MiB;
  • the published R9-v2 authority set is frozen against exact commit f7e340cf63b805885d3d977565ca234713277b11, separately from the older R9-v1 implementation baseline.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Content-addressed v2 authority freeze

  • R9-v2 authority immutability no longer depends on a historical commit being reachable after squash/rebase;
  • CI pins exact Git blob identities for RETRO-v2.md, machine/retro-v2.json, and machine/project-v12.json and compares the checked-out file contents with git hash-object;
  • Windows 95 E3 accepts canonical retail punctuation such as Windows 95. [Version 4.00.950] while preserving exact 4.00 family matching;
  • Classic Mac PowerPC E4 accepts canonical PowerPC 603e identities.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

Target payload provenance and Classic Mac execution envelope

  • E3 source revisions must contain the target-specific guest proof source and build entrypoint, not merely resolve as Git commits;
  • Classic Mac PowerPC E4 uses an explicit published-release allowlist, rejecting impossible versions such as 9.99.99;
  • Classic Mac m68k E3 matches the fixed q800/68040 harness and requires System 7.1 through Mac OS 8.1, so System 6 cannot mint q800 evidence;
  • the content-addressed R9-v2 authority blob pins were refreshed after these normative changes.

All R1-R9 workflows and the R9 Historical Target Harnesses workflow are green on this exact head.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @EmergentMonk, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 6 days and 14 hours by commenting @sourcery-ai review. Upgrade to get a review now.

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 27, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-09-27T16:29:02.108878Z 8c50e8e Manual request
🔒 Security Review ✅ Completed 2026-09-27T04:54:35.619383Z 8d41c2c PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@sourcery-ai

sourcery-ai Bot commented Sep 27, 2026

Copy link
Copy Markdown

Reviewer's Guide

Completes the R9 Retro v2 implementation machinery by freezing the prior source boundary, adding source-bound WEB1 guest proofs and strict E3/E4 receipt contracts, implementing Windows 9x, Classic Mac, and Amiga payload/full-system harnesses, and wiring PR/manual CI with SHA-256-gated proprietary media handling. The PR intentionally establishes evidence paths rather than support claims; reviewers should focus on target build correctness, emulator/media injection behavior, proof integrity, portability, and whether retained receipts accurately support the stated claims.

Sequence diagram for source-bound R9 E3 guest proof

sequenceDiagram
    participant Workflow
    participant Host as Host harness
    participant Guest as Historical guest OS
    participant Payload as Source-bound WEB1 payload
    participant Validator as r9_e3_receipt.py

    Workflow->>Host: Download user-supplied media and ROM
    Host->>Host: Verify SHA-256 digests
    Host->>Host: Build payload with source revision and target profile
    Host->>Guest: Inject payload into guest filesystem
    Host->>Guest: Start full-system emulator
    Guest->>Payload: Execute local WEB1 proof
    Payload-->>Guest: Write target, source, ABI and proof counters
    Guest-->>Host: Expose guest-proof.txt
    Host->>Validator: Mint receipt from proof and digests
    Validator->>Validator: Validate frozen WEB1 identities and target ABI
    Validator-->>Workflow: Passing E3 receipt or rejection
Loading

Flow diagram for R9 evidence claim gating

flowchart TD
    Build["Payload builds"] --> Harness["Full-system harness exists"]
    Harness --> Media["Pinned guest and ROM media verified"]
    Media --> Execute["Named historical guest executes payload"]
    Execute --> Proof["Guest reproduces frozen WEB1 proof"]
    Proof --> E3["Passing target-specific E3 receipt retained"]
    E3 --> Claim["Target support claim may be considered"]
    Hardware["Physical hardware run"] --> E4["Strict E4 receipt with hardware identity and hashed attachments"]
    E4 --> Claim
    Build -. "not sufficient" .-> Unclaimed["Target remains unclaimed"]
    Harness -. "not sufficient" .-> Unclaimed
    Execute -. "without passing proof" .-> Unclaimed
Loading

File-Level Changes

Change Details Files
Defines the Retro v2 authority and machine contracts while preserving the frozen R1–R9-v1 source boundary.
  • Adds the E3/E4 evidence rules, source-binding requirements, media non-redistribution policy, and claim boundaries.
  • Updates repository status, roadmap, agent guidance, and static landing-page links to describe harness-ready but unclaimed targets.
  • Adds machine-readable project and Retro v2 contracts.
RETRO-v2.md
machine/retro-v2.json
machine/project-v12.json
AGENTS.md
README.md
ROADMAP.md
index.html
Adds a common source-bound guest WEB1 proof and strict receipt validation for emulated and physical evidence.
  • Embeds target profile, Git revision, pointer width, and endianness in each guest payload and verifies the frozen WEB1 proof identities.
  • Validates E3 proof fields, target ABI expectations, source revision, and SHA-256 metadata before emitting receipts.
  • Validates E4 hardware identity, proof values, hashed attachments, schema, and pass status.
  • Adds receipt self-tests and evidence-retention templates/documentation.
evidence/r9_guest_browser_proof.c
scripts/r9_e3_receipt.py
scripts/r9_validate_physical_receipt.py
tests/r9_e3_e4_receipt_selftest.py
evidence/retro/README.md
evidence/retro/physical-receipt.example.json
Implements source-bound payload builds for Windows 9x, Classic Mac, and Amiga target profiles.
  • Builds a static 32-bit Win32 payload with MinGW and verifies its PE architecture.
  • Builds Classic Mac m68k and PowerPC applications through Retro68.
  • Builds the Amiga m68k executable with the Amiga GCC toolchain.
  • Records payload hashes and toolchain/container identity where applicable.
scripts/r9_build_windows9x_payload.sh
scripts/r9_build_classic_mac_payload.sh
scripts/r9_build_amiga_payload.sh
Adds full-system guest harnesses that inject payloads into user-supplied historical OS media and extract guest proof output.
  • Copies and mutates Windows disk images through guestfish, runs the payload under QEMU i386, and retains proof plus Windows version output.
  • Injects Classic Mac applications into HFS Startup Items and runs q800 or mac99 guests under QEMU.
  • Injects the Amiga executable and startup sequence into a selected HDF partition and runs it under FS-UAE.
  • Enforces runtime limits, source-revision matching, and guest-proof presence before receipt creation.
scripts/r9_windows9x_full_system.sh
scripts/r9_classic_mac_full_system.sh
scripts/r9_amiga_full_system.sh
Adds CI and manual workflows for payload builds, harness execution, source freezing, media digest gates, and artifact retention.
  • Adds PR checks for frozen-source preservation, JSON/Python/shell syntax, receipt contracts, and all target payload builds.
  • Adds manually dispatched Windows 9x, Classic Mac, and Amiga workflows that validate operator-provided SHA-256 digests before downloading proprietary media.
  • Uploads receipts, guest proofs, logs, payload hashes, and toolchain metadata as workflow artifacts.
.github/workflows/r9-target-harnesses.yml
.github/workflows/r9-windows9x.yml
.github/workflows/r9-classic-mac.yml
.github/workflows/r9-amiga.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8d41c2cbfc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread .github/workflows/r9-windows9x.yml Outdated
Comment thread .github/workflows/r9-windows9x.yml Outdated
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_windows9x_full_system.sh Outdated
Comment thread evidence/r9_guest_browser_proof.c Outdated
@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 319fd30f4a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/r9_e3_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_e3_receipt.py Outdated
@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 665e701fe2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_e3_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py

Copy link
Copy Markdown
Member Author

@codex review

Fresh review requested on head e57df50779510480e38515d68558793d45417be6. This head fixes release-specific Classic Mac CPU floors, explicit AmigaOS release validation plus 3.5/3.9 CPU/RAM floors, bounded E4 receipt reads, JSON-root validation, and target-bound E3 emulator identities recorded by the workflows. Exact regressions are retained for all five reported cases, authority blob pins are refreshed, and the receipt-contract/frozen-source/Windows/Classic-Mac jobs are green.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e57df50779

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread .github/workflows/r9-target-harnesses.yml Outdated
Comment thread .github/workflows/r9-target-harnesses.yml Outdated
Comment thread machine/retro-v2.json Outdated
Comment thread scripts/r9_e3_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py Outdated
EmergentMonk added a commit that referenced this pull request Sep 27, 2026
Install the base-branch pull_request_target trust anchor used to independently validate R9 authority blobs and PR #12's frozen-surface allowlist.
@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cdba5d6a72

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_e3_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py
Comment thread scripts/r9_validate_physical_receipt.py

Copy link
Copy Markdown
Member Author

@codex review

Fresh review requested on head 335a4ea809a3bc6f9ac8947791db511cb06598d1. This head adds E4 WEB1 source-presence binding, raises Amiga E3 to the fixed A1200 Exec/DOS 39..45 envelope, accepts canonical 68EC020 physical CPU identity, rejects NaN/Infinity/-Infinity during E4 JSON parsing, and enforces target-level physical RAM ceilings. Exact regressions are retained for all five reported cases. The base-owned R9 authority pins were rotated via PR #14 and the independent immutable-r9-boundary check is green on this head.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 335a4ea809

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/r9_validate_physical_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py Outdated

Copy link
Copy Markdown
Member Author

@codex review

Fresh review requested on head 77e1beef128301c22e5ffdf13a05d389826e8a52. E4 source binding now requires the exact frozen R8 Git blob identities for the WEB1 proof entrypoint, browser implementation, and public browser header; a locally-created zero-byte source commit is retained as a negative regression. Classic Mac E4 now accepts canonical 68LC040 hardware, and identity/evidence-name strings reject C0/DEL controls before trimming. The base-owned authority pins were rotated via PR #15, the independent immutable-r9-boundary check is green, receipt-contract is green, all target payload builds are green, and all reported review threads are resolved.

@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 77e1beef12

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread RETRO-v2.md Outdated
Comment thread scripts/r9_e3_receipt.py Outdated
Comment thread scripts/r9_validate_physical_receipt.py Outdated
@EmergentMonk

Copy link
Copy Markdown
Member Author

@codex Please Review this exact SHA 8c50e8e against the existing contract. Report only actionable correctness defects, with a minimal reproduction, expected versus actual behavior, and affected lines. State whether each reproduction was executed or statically inferred. Don’t repeat fixed findings without a new failing case. Keep architectural suggestions separate and non-blocking.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Nice work!

Reviewed commit: 8c50e8eb3b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@EmergentMonk
EmergentMonk merged commit 6445406 into main Sep 27, 2026
100 checks passed
@EmergentMonk
EmergentMonk deleted the r9/e3-e4-targets branch September 27, 2026 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant