1.0, 1.1, and 2.0Long-term directions still exist, but only the three stages already in real motion are stated publicly.
Editions & Roadmap
Editions & Roadmap
Version PlanThe public roadmap still speaks in
1.0, 1.1, and 2.0, but the real usage path has already split into four layers: the free path, local script slots, the standard team edition, and enterprise delivery.The version stages describe the platform build rhythm. The four layers describe which path a user should take. Those two things should not be mixed together.
The current rhythm is better understood like this: 1.0 stabilizes real delivery, trusted execution, and local onboarding first, 1.1 fills in auto-registration, payment, renewal, and a lower-support loop, and 2.0 decides which paths are worth continuing as more standardized solutions. Multi-Skill orchestration is not a default capability today. It should enter formal productization only after the governance base is stronger.
The current core position of 1.0 is this: ExecFabric is a multi-tenant governance and execution platform that treats Python scripts as the first mature execution asset.
Later 3.0 and 4.0 directions still exist in internal long-term planning, but the public roadmap only talks about 1.0, 1.1, and 2.0 so long-term ideas are not mistaken for current capability.
As of the current version, 1.0 has already completed its first compatibility-oriented upgrade: the general resource layer and executor registry layer have landed, and the first non-script capability sample is HTTP capability access in the public super-admin domain. The next priority is still not to spread horizontally into more capability types. It is to make 1.1 auto-registration, payment, renewal, and shutdown-recovery into a lower-support loop first.
This round also tightened the boundary further: HTTP capability access remains available only inside the public governance domain, whitelisted tenant admins keep only a minimal cross-tenant console, and the system no longer misidentifies administrators through unsafe conditions such as user_id == 1.
At the same time, the first real segment of 1.1 has already landed: the public order center supports order creation, payment confirmation, activation execution, renewal-reminder scans, and expiry-shutdown scans. The personal free edition also already has the first version of the billing center for local script slots, and the free path now includes explanations for monthly and annual registration into the team edition. A complete general subscription center, real third-party payment gateways, and outbound reminder channels are still not finished.
The shared-SaaS tenant frontend skeleton is also in place: starting from tenant_1003+, standard SaaS customers no longer default to cloning one frontend project per customer. They first go through the shared tenant frontend instead. It can already carry the formal tenant entry, but dynamic branding, initialization, and finer customization boundaries are still being tightened.
1.0 trusted delivery1.1 lower-support loop2.0 next-stage convergencecontinuous upgradeexpand on demand
EXECFABRIC // ROADMAPDOC 06
1.0: delivery_ready / trusted_execution1.1: self_serve_trial / renewal_loop2.0: productize_proven_paths
ROADMAP SHOULD FOLLOW REAL DEMAND
Stabilize delivery, entry-point closure, and reusable capabilities first, then decide which parts deserve more product thickness.
If you are evaluating whether this platform is ready for onboarding now, use the four checks below first instead of being pulled off course by long-term planning.
NowThe core of
1.0 is trusted delivery, script onboarding, and multi-tenant governanceBeing filled in
1.1 focuses on auto-registration, renewal, and a lower-support loopLater decision
2.0 is where the product decides which paths deserve deeper standardizationDo not misreadMulti-step orchestration and the longer-term
3.0 / 4.0 directions are still not current promised capability1.0
Trusted AI execution delivery edition
- One customer, one tenant
- Unified capability catalog, script onboarding, and Skill mapping
- Python scripts are currently the first mature execution asset
- The general resource layer and executor registry layer have already landed
- A first sample of HTTP capability access already exists on the
publicsuper-admin side, while tenant-side access is still limited to a read-only ledger - Whitelisted tenant admins currently keep only a minimal cross-tenant console and do not get the platform-governance pages directly
- Administrator detection now closes around explicit admin or super-admin markers and no longer relies on
user_id == 1 - Recommendation, confirmation, execution, and audit for the intelligent brain
- Template distribution, installation, rollback, and logs
- The no-login experience page, login, signup, signup result page, the personal-free menu set, the HTTP read-only ledger, lightweight self-service purchase of local script slots, and the smallest
execfabric-cliloop
Next
These are the next things to tighten first
- Turn auto-registration, entry-point activation, payment, renewal, expiry reminders, and shutdown flows into a lower-support loop
- Turn the highest-frequency capabilities in small-team collaboration into more stable solutions
- Converge packages, quotas, and delivery boundaries into clearer product rules
- Continue tightening branding, initialization, and menu boundaries in the shared-SaaS frontend into a stable solution
- Turn CLI and Local Agent binding codes, heartbeat, status, and remote execution into a more formal solution
- Continue converging real third-party payment, outbound reminders, shared-SaaS branding, and remaining lifecycle automation into a stable external narrative
1.1 Now
The first landed segment of 1.1
- The
publicsuper-admin order center has already switched into a real lifecycle mode - It already supports order creation, payment confirmation, activation execution, renewal-order prefilling, renewal-reminder scans, and expiry-shutdown scans
- The personal free frontend already has lightweight self-service local script-slot purchase and an explanation of monthly or annual team-edition registration entry points
- Order state, customer state, and tenant state already write back together instead of staying as sample-only display
1.1 Pending
The parts of 1.1 that are not finished yet
- A complete general subscription center for the personal free path, end-user self-service renewal and auto-charge entry points, and deeper reconciliation capability
- Real third-party payment gateways, signature verification, and formal payment callbacks
- Outbound reminder channels such as email, enterprise WeChat, and SMS
Path Ladder
Above the version stages, how the real usage path is layered today
| Layer | Current carrying path | Relationship to the roadmap | Suggested entry |
|---|---|---|---|
| Free path | Public experience, login and signup, personal entry | Part of the already-established customer-acquisition and experience entry of 1.0 | Getting Started |
| Local script-slot expansion | Lightweight personal-space expansion | The first landed loop of 1.1, not the same thing as a complete general subscription center | Billing & Membership |
| Standard team edition | Shared-SaaS formal tenant entry | Still converging around the 1.0 delivery base and the 1.1 upgrade path | Customer Flow / Delivery |
| Enterprise delivery | Single-tenant delivery, private deployment, or deeper deployment control | The most mature formal-delivery mainline under current 1.0 | Deployment |
1.0 Core
Current focus of 1.0
- Python scripts as the first mature execution asset
- Skill remains the user-visible capability unit
- The resource layer and executor registry layer are already in place, so connecting a second or third capability type should not require another large schema rewrite
- Delivery, execution, security boundaries, and continuous updates are becoming one loop
- Single-capability execution is already usable
- The local bridge and CLI support deeper onboarding
2.0 Expansion
What 2.0 continues to expand
- After the lower-support loop of
1.1is stable, continue turning auto-registration, payment, renewal, prompts, and self-service support into more stable standard solutions - A more general capability-asset registration model
- More capability onboarding such as APIs, data connectors, document templates, and approval flows
- Multi-Skill or multi-step orchestration only enters real development after composite-demand decomposition, node-level confirmation, formal downgrade or rollback, and partial-success and recoverable-state handling are in place
- Further generalization of installation, distribution, upgrade, and rollback strategies
- Continued convergence of small-team collaboration, packaging, and standard capability boundaries
Upgrade Route
How version stages carry the path from free entry to formal delivery
01. Feel the value through the free entry
Use the public experience page, login, signup, and signup result page to understand what the platform is first. After login, the personal entry currently continues through the valid personal-free menu set, the HTTP read-only ledger, and the lightweight local script-slot expansion entry so the user can verify whether the AI scheduling chain is real.
02. Keep individual usage on local script slots first
If the user is already continuously connecting scripts in personal space but is not yet in multi-user collaboration, the better current path is lightweight local script-slot expansion first. CLI and the local bridge are support capabilities, not a separate commercial line.
03. Move multi-user collaboration into the standard team edition first
If the customer mainly needs standard capability and lighter collaboration, the current best path is the formal tenant entry carried by the shared-SaaS frontend, to verify first whether the standard team path is enough.
04. Move into enterprise delivery when the boundary is stronger
If the project involves intranet access, stronger isolation, exclusive branding, exclusive pages, or formal project acceptance, continue into enterprise 1.0 single-tenant delivery. 2.0 is where the reusable path becomes thicker later.
Current Upgrade Logic
How the upgrade path moves
- Step one: let users feel the value through the free entry first
- Step two: if they are still in personal continuous usage, continue with lightweight local script-slot expansion first
- Step three: when they move into multi-user collaboration, let the formal tenant entry of the standard team edition take over first
- Step four: when stronger isolation and formal acceptance are needed, move into enterprise
1.0delivery while continuing to stabilize the lower-support loop of1.1
What 2.0 Changes
How this path changes after 2.0
- The boundaries between the free entry, small-team plans, and formal delivery will become clearer
- Packages, quotas, resources, conversion, and operating metrics will converge into clearer rules
- The parts inside CLI and Local Agent that prove real value will continue moving toward a stable solution
- The path of "try first, then upgrade by scenario" will finally become a standardized chain
1.0 Companion Docs
To judge whether 1.0 has really landed, continue with these three pages
FilesFiles & Results
Many 1.0 projects do not return text only. They need to handle input files, batch states, and result files, and this chain deserves its own explanation.
To judge whether 1.0 is really deliverable, it is more useful to see which entry points, instructions, and result artifacts the customer actually gets than to stare at feature names.
When a real project is about to move, preparing the script directory, README, sample files, dependencies, and risk boundaries is more valuable than continuing to talk abstractly about version numbers.
Near-Term Focus
The standard service packages that fit the current stage
E-commerce, content, and operations-data automation
Turn scattered scripts, spreadsheet handling, and data-organizing tasks into stable entry points first. These are the easiest scenarios to close early and the easiest to reuse later.
Script governance and automation ops for technical teams
Build a delivery line around script governance, task scheduling, log traces, and local execution bridging. This stays closest to the current capability boundary.
Small formal customers that need intranet access or private deployment
These customers validate multi-tenant isolation, permission boundaries, and the formal delivery chain best, but customization depth still needs to be controlled so only platform-strengthening projects are taken.
Why Both Lines
Why the formal-customer line and the free path run in parallel
- If the product did only the enterprise line, individuals and small teams would lack a low-friction validation entry
- If it did only the free path, formal delivery, isolated governance, and long-term usage would stay incomplete
- So the current route stays as follows: formal customer delivery under
1.0carries formal scenarios, while the personal free edition carries experience and upgrade entry points, and both lines share the same trusted-execution base
Current Rhythm
Current version rhythm
1.0is the current main delivery line with usable foundations already in place1.1prioritizes stabilizing auto-registration, payment, renewal, reminders, and lower-support handling2.0is the next stage of standardization and convergence- More capabilities will expand gradually according to real demand