Pre-Ajax Migration Complete: Stabilization and Backlog Consolidation

[alteixeira20]

As part of the work leading into Ajax and the next Odysseus release, we completed the migration of a substantial runtime and security hardening cycle back into the public repository.

Important

Migration complete, October 6, 2026

The pre-Ajax migration has been merged into public dev through #6503.

The temporary dev freeze is lifted.

We are now moving into the public stabilization and backlog-consolidation phase. Existing issues and pull requests will be reevaluated against the new baseline so that work which has already been fixed, replaced, duplicated, or superseded can be closed with context, while still-relevant work remains available to contributors.

This was a coordinated integration operation rather than a normal feature merge. The goal was to bring the new runtime baseline back into the public repository carefully, preserve the project’s development history and contributor attribution, validate the resulting code as a complete system, and establish a clean baseline for the next development cycle.

At a glance

Current state	Pre-Ajax migration complete, public dev in stabilization
Migrated baseline	Pre-Ajax runtime and security hardening
Migration PR	#6503
Public dev merge	2cd02da7fc5d500fa86511f2a36ddb431de532c8
History	Preserved as far as Git technically allows
Current work	Public stabilization and issue/PR consolidation
Next milestone	Broader validation and remaining known-issue cleanup
Final destination	main, after the new dev baseline is validated

Note

Landing on dev does not mean the release is finished.

It marks the public stabilization phase. We will work through remaining edge cases, test the complete baseline more broadly, consolidate the existing backlog, and document any remaining known issues before promotion to main.

---

Why this work was developed separately

Over the previous development cycle, several parts of the Odysseus runtime became tightly coupled enough that changing them independently would have created unstable intermediate contracts for contributors.

The work spans areas including:

• resource ownership and authority
• process identity and lifecycle
• containment and execution boundaries
• background jobs and follow-up delivery
• browser execution
• local-control authorization
• cancellation, teardown and recovery
• effect verification
• CI and release validation

Rather than repeatedly changing those contracts on public dev, we used an isolated maintainer integration environment to develop, review and validate the changes together.

Important

That isolation was an integration strategy, not a change in Odysseus open-source direction.

That work has now returned to the public repository.

---

What changed

A major focus of this cycle was making runtime behavior more explicit and verifiable.

The migrated baseline introduces stronger separation between:

discovery
    ↓
ownership
    ↓
authorization
    ↓
execution
    ↓
evidence

Process identity and ownership are no longer treated as equivalent to simply knowing a PID.

Execution and containment boundaries have been hardened. Foreground and background lifecycle behavior has been made more explicit. Cancellation, cleanup, recovery and restart paths received additional validation.

We also tightened how Odysseus determines whether an action actually succeeded.

Note

Successful execution is not the same thing as verified effect.

The runtime increasingly distinguishes between a tool reporting success and Odysseus having evidence that the intended external state actually changed.

This work also prepares the runtime and harness for Ajax and the next phase of local model integration.

---

How the migration was completed

We did not replace the repository with a new snapshot or squash months of work into one opaque commit.

The migration preserved the underlying public Git history, authorship and contributor attribution while sanitizing private-only development history before publication.

frozen private runtime baseline
        ↓
history / privacy / ancestry audit
        ↓
reconciled release candidate
        ↓
public pre-Ajax integration branch
        ↓
public review + release validation
        ↓
dev
        ↓
public stabilization + issue consolidation
        ↓
final verification
        ↓
main

The public migration was completed through #6503.

The final qualified migration head was:

ee13ed1eeea4f1f5a8362e7b34aff03829156a7d

It was merged into public dev as:

2cd02da7fc5d500fa86511f2a36ddb431de532c8

Caution

Nothing is going directly to main.

dev remains the stabilization baseline. Promotion to main will happen only after the migrated baseline has completed broader public validation.

What was preserved

The migration retained:

• public repository history;
• contributor commits and attribution;
• authorship and commit messages;
• the development history behind the new runtime;
• the existing public lineage while the two development lines were reconciled.

Private-only material was audited and sanitized before becoming publicly reachable.

---

dev is now the stabilization baseline

Getting the migration onto dev was a major milestone, but it is not the point where we declare the release finished.

We are now using the public stabilization phase to:

1. exercise the complete runtime more broadly;
2. work through remaining integration issues and edge cases;
3. validate behavior that only becomes visible once the full system is running together;
4. reevaluate the existing issue and pull-request backlog;
5. close work that has genuinely been superseded;
6. document remaining known issues;
7. give contributors a clear and current set of problems to work from;
8. complete the final verification required before promotion to main.

This gives contributors a stable public target without presenting the first dev migration as a finished release.

---

What happens to existing issues and pull requests

The migrated runtime changes enough of the system that a significant number of existing issues and pull requests now need to be reevaluated.

Existing work	What happens
Still applicable	Kept and reevaluated against the new baseline
Needs adaptation	Updated to fit the current runtime contracts
Already fixed	Closed with evidence of the current implementation
Already addressed differently	Closed as superseded with context
Duplicate of newer work	Consolidated into the canonical issue or PR
Targets replaced implementation	Closed as superseded
Partially resolved	Remaining actionable work identified explicitly
Still reproduces after migration	Kept or updated against the new baseline

Important

Superseded does not mean ignored.

A number of reports and contributions directly influenced the runtime work that has now been migrated. In other cases, the same underlying problem is now addressed through a different implementation.

We are now performing a repository-wide backlog consolidation against the current dev.

Every open issue and pull request will be checked against the migrated implementation before a closure decision is made.

Items will not be closed simply because they are old or inactive.

Where something has genuinely been fixed, duplicated, replaced, or superseded, we will close it with enough context to explain what happened.

Still-relevant work will remain open or be updated against the current baseline.

The goal is to give contributors a clear, current and actionable backlog instead of asking people to navigate issues and pull requests that partly describe an implementation which no longer exists.

If an older issue still reproduces against the current baseline, updated reproduction information is especially useful.

---

Guidance for contributors after the migration

The migration is complete and the temporary dev freeze has been lifted.

New work should target the current public dev.

Before investing significant effort in older runtime-related issues or pull requests, please check them against the current baseline. The backlog is actively being consolidated, and some older work may already have been addressed or superseded by the migrated runtime.

This is particularly relevant to work involving:

• tool execution;
• browser tooling;
• background jobs;
• process handling;
• authorization;
• runtime lifecycle;
• containment;
• agent/runtime contracts;
• test infrastructure around those systems.

Tip

If you are working from an older issue or pull request, first verify that the behavior still exists on current dev.

If it does, updated reproduction details or a refreshed implementation against the new baseline will help us move it forward.

Normal contribution flow can resume against dev, while maintainers continue the stabilization and backlog-consolidation pass.

---

What happens next

The migration itself is complete.

The immediate goal is now to establish a clean and well-understood public baseline where:

• the migrated history is intact;
• existing public contributor history remains intact;
• private/internal development material was audited before publication;
• migration conflicts were resolved semantically rather than by blindly preferring one side;
• the migrated runtime passed the release qualification required for publication;
• the pre-Ajax migration was merged into public dev;
• the public dev baseline has completed broader stabilization testing;
• superseded issues and pull requests have been fully reconciled against the new baseline;
• remaining known issues are documented so contributors can focus efficiently;
• the resulting release candidate has undergone any remaining independent adversarial review required before promotion;
• final verification has completed before promotion to main.

The next immediate maintainer task is the repository-wide issue and pull-request cleanup.

That pass will classify open work as:

still valid
fixed
superseded
duplicate
no longer applicable
partially resolved
needs further verification

Closure decisions will be evidence-driven rather than based on age or inactivity.

We will continue updating this Discussion as stabilization progresses toward the eventual promotion of dev to main.

---

Open source and contributions

Odysseus remains an open-source project, and contributions remain a core part of how it develops.

Thanks to everyone who has reported issues, submitted pull requests, tested the project, reviewed the migration, and helped identify the weak points that informed this work.

The pre-Ajax migration has now returned that development work to the public repository as a coherent baseline.

The next step is to clean up the backlog, make the remaining work explicit, and continue building from a public dev that accurately represents the current Odysseus architecture.

[alteixeira20]

Pre-Ajax migration update:

The qualified migration candidate is now public as PR #6503, tracking issue #6502.

• PR: chore(release): publish qualified pre-Ajax migration #6503
• FREEZE 2 commit: 4b140043bbf8d0104004cbb8bc42cf71ceaa488b
• FREEZE 2 tree: bd6a96a492352d26e1601e8932ce4465bd74f027
• Base: public dev at 2992bf6d368a11472323e47d3bfed91e79cefc6b

The candidate completed the pre-publication qualification gates with all four public pytest shards passing and no candidate regressions.

Public CI and independent review are now in progress. We will not merge until the final dev drift gate is clean. A further update will follow after merge and exact migrated-baseline validation.

[alteixeira20]

Pre-Ajax migration complete

PR #6503 has been merged into public dev.

• Migration PR: chore(release): publish qualified pre-Ajax migration #6503
• Final qualified migration head: ee13ed1eeea4f1f5a8362e7b34aff03829156a7d
• Public dev merge commit: 2cd02da7fc5d500fa86511f2a36ddb431de532c8
• Migration history and contributor attribution were preserved
• Final public qualification completed successfully
• The temporary dev freeze is now lifted

This moves us into the next phase described in the original post: public stabilization and backlog consolidation.

What happens next

We are going to review the existing issue and pull-request backlog against the new dev baseline.

For each open issue and PR we will determine whether it:

• still applies to the current implementation;
• has already been fixed by the migrated baseline;
• was implemented differently;
• duplicates newer work;
• targets code or architecture that has since been replaced;
• is partially resolved but still contains useful work;
• still requires implementation or further investigation.

Items will not be closed simply because they are old.

Where something has genuinely been superseded, we will close it with context explaining what replaced or resolved it. Still-valid reports and contributions will remain open or be updated against the current baseline.

The goal is to leave Odysseus with a smaller, accurate and actionable backlog before the next development cycle begins.

After that consolidation pass, we will continue broader stabilization and validation of dev before the eventual promotion to main.

[rauljua]

Has work started on the consolidation?