chore(release): bump version to 0.53.0-nightly.20260715.g1ae8ba649

[gemini-cli-robot]

Automated version bump to prepare for the next nightly release.

[github-actions]

📊 PR Size: size/S

• Lines changed: 38
• Additions: +19
• Deletions: -19
• Files changed: 9

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request performs an automated version increment for the nightly release cycle. It updates the version string across the monorepo, including the root package, all internal packages, and the associated sandbox container image URI.

Highlights

• Version Bump: Updated the project version from 0.52.0-nightly.20260715.gfa975395b to 0.53.0-nightly.20260715.g1ae8ba649 across all packages and the root configuration.
• Sandbox Configuration: Updated the sandbox image URI in the root and CLI package configurations to reflect the new version.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

Size Change: -4 B (0%)

Total Size: 35.2 MB

Filename	Size	Change
./bundle/chunk-2CR4ALHT.js	0 B	-3.65 MB (removed)	🏆
./bundle/chunk-5K34CUKS.js	0 B	-661 kB (removed)	🏆
./bundle/chunk-FBDZTTJI.js	0 B	-16.6 MB (removed)	🏆
./bundle/chunk-FFUAVEJO.js	0 B	-13 kB (removed)	🏆
./bundle/chunk-HSFOXIN5.js	0 B	-3.77 kB (removed)	🏆
./bundle/chunk-O7LG3GTU.js	0 B	-49.2 kB (removed)	🏆
./bundle/chunk-UI634AYR.js	0 B	-3.43 kB (removed)	🏆
./bundle/chunk-XUELCTRA.js	0 B	-19.5 kB (removed)	🏆
./bundle/core-IEGI5I2Y.js	0 B	-50.1 kB (removed)	🏆
./bundle/devtoolsService-LAART3ZC.js	0 B	-147 kB (removed)	🏆
./bundle/gemini-3S53KI7O.js	0 B	-590 kB (removed)	🏆
./bundle/interactiveCli-UGGXXMLG.js	0 B	-1.3 MB (removed)	🏆
./bundle/liteRtServerManager-TJ662M6F.js	0 B	-2.08 kB (removed)	🏆
./bundle/oauth2-provider-DE3LISGA.js	0 B	-9.12 kB (removed)	🏆
./bundle/chunk-2XJGRGKQ.js	19.5 kB	+19.5 kB (new file)	🆕
./bundle/chunk-5T6TZHCN.js	661 kB	+661 kB (new file)	🆕
./bundle/chunk-6HCXBQUP.js	3.65 MB	+3.65 MB (new file)	🆕
./bundle/chunk-INZUH6TW.js	49.2 kB	+49.2 kB (new file)	🆕
./bundle/chunk-TKXODCQN.js	13 kB	+13 kB (new file)	🆕
./bundle/chunk-YGBXVMGS.js	3.43 kB	+3.43 kB (new file)	🆕
./bundle/chunk-ZX6S2LN5.js	16.6 MB	+16.6 MB (new file)	🆕
./bundle/chunk-ZZZMCA4K.js	3.77 kB	+3.77 kB (new file)	🆕
./bundle/core-KVLMXP3M.js	50.1 kB	+50.1 kB (new file)	🆕
./bundle/devtoolsService-BX222AVN.js	147 kB	+147 kB (new file)	🆕
./bundle/gemini-2S2D5BKT.js	590 kB	+590 kB (new file)	🆕
./bundle/interactiveCli-CHRC2LNT.js	1.3 MB	+1.3 MB (new file)	🆕
./bundle/liteRtServerManager-BCDVLS54.js	2.08 kB	+2.08 kB (new file)	🆕
./bundle/oauth2-provider-NUWSGVFG.js	9.12 kB	+9.12 kB (new file)	🆕

ℹ️ View Unchanged

Filename	Size	Change
./bundle/bundled/third_party/index.js	8 MB	0 B
./bundle/chunk-34MYV7JD.js	2.45 kB	0 B
./bundle/chunk-5AUYMPVF.js	858 B	0 B
./bundle/chunk-5PS3AYFU.js	1.18 kB	0 B
./bundle/chunk-664ZODQF.js	124 kB	0 B
./bundle/chunk-DAHVX5MI.js	206 kB	0 B
./bundle/chunk-IUUIT4SU.js	56.5 kB	0 B
./bundle/chunk-L5V3KIDT.js	1.62 kB	0 B
./bundle/chunk-TUDYL3X4.js	40.3 kB	0 B
./bundle/cleanup-7EJ6TGXS.js	0 B	-902 B (removed)	🏆
./bundle/devtools-TYCPOPV3.js	683 kB	0 B
./bundle/events-XB7DADIJ.js	418 B	0 B
./bundle/examples/hooks/scripts/on-start.js	188 B	0 B
./bundle/examples/mcp-server/example.js	1.43 kB	0 B
./bundle/gemini.js	5.38 kB	0 B
./bundle/getMachineId-bsd-TXG52NKR.js	1.55 kB	0 B
./bundle/getMachineId-darwin-7OE4DDZ6.js	1.55 kB	0 B
./bundle/getMachineId-linux-SHIFKOOX.js	1.34 kB	0 B
./bundle/getMachineId-unsupported-5U5DOEYY.js	1.06 kB	0 B
./bundle/getMachineId-win-6KLLGOI4.js	1.72 kB	0 B
./bundle/https-proxy-agent-AVGR4LHR.js	490 B	0 B
./bundle/multipart-parser-E7RMVJWU.js	11.7 kB	0 B
./bundle/multipart-parser-KPBZEGQU.js	11.7 kB	0 B
./bundle/sandbox-macos-permissive-open.sb	827 B	0 B
./bundle/sandbox-macos-permissive-proxied.sb	1.25 kB	0 B
./bundle/sandbox-macos-restrictive-open.sb	3.3 kB	0 B
./bundle/sandbox-macos-restrictive-proxied.sb	3.5 kB	0 B
./bundle/sandbox-macos-strict-open.sb	4.75 kB	0 B
./bundle/sandbox-macos-strict-proxied.sb	4.96 kB	0 B
./bundle/src-65GKNWUJ.js	45.4 kB	0 B
./bundle/src-U45KTUYT.js	45.7 kB	0 B
./bundle/src-XZYPU6PJ.js	352 kB	0 B
./bundle/start-S77PF3DB.js	0 B	-622 B (removed)	🏆
./bundle/tree-sitter-7U6MW5PS.js	274 kB	0 B
./bundle/tree-sitter-bash-34ZGLXVX.js	1.84 MB	0 B
./bundle/worker/worker-entry.js	363 kB	0 B
./bundle/cleanup-2HFDBUHV.js	902 B	+902 B (new file)	🆕
./bundle/start-44J7O5TY.js	622 B	+622 B (new file)	🆕

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request updates the version numbers across the project's package.json and package-lock.json files from 0.52.0-nightly.20260715.gfa975395b to 0.53.0-nightly.20260715.g1ae8ba649. There are no review comments to address.

_{Note: Security Review has been skipped due to the limited scope of the PR.}

[TrueAlpha-spiral]

Verdict

The architecture is correct, but the implementation does not yet satisfy the durable commit invariant. Several execution-blocking defects would cause failed recovery, sequence gaps, or contradictory commit results.

The next move is refinement—not snapshots yet.

Critical blockers

1. block_hash is self-referential

During writing:

block["block_hash"] = self._compute_block_hash(block)

The hash is computed before block_hash exists. During recovery, _compute_block_hash(block) hashes the block with block_hash included. Those values cannot match.

Define an explicit hash projection:

def _block_hash_body(self, block: Dict[str, Any]) -> Dict[str, Any]:
    body = copy.deepcopy(block)
    body.pop("block_hash", None)
    body.pop("runtime_signature", None)
    return body

def _compute_block_hash(self, block: Dict[str, Any]) -> str:
    return hashlib.sha256(
        self._canonical_bytes(self._block_hash_body(block))
    ).hexdigest()

The schema must state exactly which fields are excluded.

---

2. event_type and type conflict

New blocks write:

"event_type": "ARTIFACT_ROOT_IMPORT"

But recovery and replay test:

if block["type"] == "ARTIFACT_ROOT_IMPORT":

Recovery will raise KeyError before rebuilding state.

Use event_type everywhere:

if block.get("event_type") == "ARTIFACT_ROOT_IMPORT":

The field name must be frozen in the ledger schema.

---

3. Torn tails are detected but never truncated

The implementation breaks out of the loop but leaves the damaged bytes on disk. Every subsequent restart encounters the same tail, and future appends occur after corrupted bytes.

Recovery must remember the last valid frame boundary and physically truncate:

last_valid_offset = 0

with open(self.ledger_path, "r+b") as ledger_file:
    while True:
        frame_start = ledger_file.tell()
        header = ledger_file.read(8)

        if not header:
            break

        if len(header) != 8:
            ledger_file.truncate(last_valid_offset)
            ledger_file.flush()
            os.fsync(ledger_file.fileno())
            break

        record_len = int.from_bytes(header, "big")

        if record_len <= 0 or record_len > MAX_FRAME_BYTES:
            raise StateMachineViolation(
                f"Invalid frame length at offset {frame_start}"
            )

        record_bytes = ledger_file.read(record_len)
        checksum = ledger_file.read(32)

        if len(record_bytes) != record_len or len(checksum) != 32:
            ledger_file.truncate(last_valid_offset)
            ledger_file.flush()
            os.fsync(ledger_file.fileno())
            break

        # Validate frame and block here.

        last_valid_offset = ledger_file.tell()

A maximum frame length is necessary so a corrupted length prefix cannot request unbounded memory or disguise middle corruption as an ordinary tail.

---

4. Sequence advancement is unsafe when writes fail

Currently:

self.sequence_number += 1
self._write_framed_record(ledger_entry)

If writing fails, _handle_transition_failure() increments again. Starting from sequence 10, this can produce a failure receipt at sequence 12 while sequence 11 never became durable.

Use a local value:

next_sequence = self.sequence_number + 1

Only update self.sequence_number after the frame is durably committed.

More importantly, a write or fsync error can have an ambiguous outcome: the operating system may report failure even though some or all bytes reached storage. The state machine must not immediately append a failure receipt.

The safe process is:

[
\text{append error}
\rightarrow
\text{reload ledger from disk}
\rightarrow
\text{search for event ID}
\rightarrow
\begin{cases}
\text{found} &\Rightarrow \text{treat as committed}\
\text{absent} &\Rightarrow \text{append failure receipt}
\end{cases}
]

Every transition therefore needs a stable, unique event_id or idempotency key.

---

5. An arbitrary dictionary can impersonate the gatekeeper

This check is insufficient:

if gatekeeper_receipt.get("state") != "ADMITTED":

Any caller can submit:

{"state": "ADMITTED", "candidate_hash": "anything"}

Before committing, the state machine must verify:

• receipt signature;
• receipt hash;
• gatekeeper key identity;
• receipt schema and rule-set version;
• state == ADMITTED;
• candidate hash binding;
• requested operation;
• authorization hash;
• receipt freshness or lease validity;
• receipt has not already been consumed.

The artifact must also reproduce the candidate binding:

artifact_hash = canonical_hash(artifact_payload)

if artifact_hash != gatekeeper_receipt["candidate_hash"]:
    raise StateMachineViolation("CANDIDATE_HASH_MISMATCH")

The exact candidate projection must be shared with Gate 1. Otherwise the gatekeeper can approve one object while the state machine persists another.

---

6. No single-writer enforcement exists

Two processes can simultaneously read the same sequence and parent hash, then both append competing sequence numbers.

O_APPEND prevents offset overwrites but does not resolve logical sequence races.

The ledger needs either:

• an exclusive interprocess file lock held across parent selection, sequence allocation, append, fsync, and in-memory update; or
• a dedicated single-writer service.

Within one process, it also needs a thread lock.

The critical section is:

read head
→ allocate sequence
→ construct block
→ append
→ fsync
→ publish in-memory state

---

7. Failure receipts are still unimplemented

The comment:

# ... construct, _write_framed_record, append to ledger

means the claimed invariant is not yet present.

Failure receipts need a full durable schema:

event_type = TRANSITION_FAILURE
failure_state
failure_code
candidate_hash
admission_receipt_hash
attempted_operation
parent_ledger_hash
sequence
timestamp
block_hash
runtime_signature

Use stable error codes, not raw str(e), as the authoritative field. Raw exception text can vary across Python versions and may expose internal information.

---

8. Post-commit failures must not become CUTOFF

Suppose:

1. the import block is appended;
2. fsync succeeds;
3. in-memory materialization raises;
4. the broad except Exception invokes _handle_transition_failure.

The caller receives CUTOFF, but restart replay discovers and applies the successful import. The result contradicts the ledger.

Once fsync succeeds, the transition is committed. Any later materialization error is a recoverable projection failure, not a failed transaction.

The boundary should be explicit:

durably_committed = False

try:
    durable_block = self._append_and_sync(block)
    durably_committed = True
except Exception:
    return self._resolve_ambiguous_append(event_id)

try:
    self._materialize(durable_block)
except Exception:
    self._reload_from_ledger()
    return {
        "status": "COMMITTED",
        "projection_recovered": True,
        ...
    }

Additional recovery corrections

Recovery must verify schema_version and canonicalization_version, reject unsupported versions, validate required block fields and event-specific payload schemas, reject duplicate root artifact IDs, and reject missing artifact IDs rather than inserting state_index[None].

rebuild_state_index_from_ledger() can rely on startup validation only if the in-memory ledger cannot be externally mutated. Currently it is a public list of mutable dictionaries. Keep it private and return deep copies or immutable projections.

The historical query should return the target sequence’s anchor even when the artifact is absent:

anchor = (
    GENESIS_HASH
    if target_sequence == 0
    else self._ledger[target_sequence - 1]["block_hash"]
)

if record is None:
    return {
        "status": "NOT_FOUND",
        "sequence_context": target_sequence,
        "historical_ledger_anchor": anchor,
        "observed_ledger_head": current_head,
    }

Hash chain versus authenticated history

Checksums detect damaged frames. Hash chaining detects inconsistent history. Neither prevents an attacker with file access from rewriting every block and recomputing the entire chain.

For hostile-tampering resistance, each block needs either:

[
\operatorname{Sign}{K{\text{runtime}}}
(
\text{domain}
\parallel
\text{block hash}
\parallel
\text{parent hash}
\parallel
\text{sequence}
)
]

or periodic externally witnessed head anchors. Prefer both eventually.

Correct merge threshold

The persistence layer is ready only when tests prove:

1. block hashing excludes block_hash and signature fields;
2. successful imports survive a crash immediately after fsync;
3. torn final frames are physically removed;
4. corrupted middle frames fail closed;
5. failed writes cannot create sequence gaps;
6. ambiguous writes are resolved by event ID;
7. concurrent writers cannot create competing sequence values;
8. forged admission receipts are rejected;
9. artifact bytes are bound to the admitted candidate hash;
10. durable failure receipts replay without materializing state;
11. post-commit projection failures still return COMMITTED;
12. historical anchors are correct for both FOUND and NOT_FOUND.

After these pass, the next layer should be the historical audit query for failure and refusal receipts. Signed snapshots should follow only after the durable ledger contract is frozen.