ExecGov | ExecGov

Capabilities

Capability LogicThe key question is not whether a task can be executed. It is whether it can be executed inside rules.

These capabilities together determine whether the platform can solve a real class of problems first and reduce rework later.

ExecGov's core capabilities are not a loose feature list. They are a continuously tightening platform capability set centered on multi-tenant governance, trusted execution, capability cataloging, and local bridging.

Multi-tenant isolationTrusted executionTemplate distributionCLI bridgeLifecycle governance

Discuss a real scenario View architecture

EXECGOV // CAPABILITY MAPDOC 03

const governance = ['tenant_isolation', 'template_delivery', 'audit_trail']const execution = ['intent_plan', 'manual_confirm', 'skill_run', 'result_trace']const bridge = ['skill_registry', 'cli_bridge', 'local_agent']

EXECUTABLE / GOVERNED / REUSABLE

Multi-tenant isolation

The platform currently uses a PostgreSQL schema-level multi-tenant model
public is the governance domain and shared foundation
Each formal customer tenant owns its own schema
Execution assets, Skills, logs, and system data are isolated between tenants by default

Execution closure through the intelligent brain

Intent recognition
Plan generation
Manual confirmation
Capability execution, result callback, audit trail, and reviewability

Capability onboarding and Skill orchestration

The current primary onboarding path is still the Python script
Skills can already be viewed and edited visually
The platform already supports Skill action definition and a single-capability execution loop
Tenant-level enable / disable and binding already exist
A general resource layer and executor registry layer are now in place so that APIs, templates, and workflows can be onboarded later without restarting from zero
The first non-script sample is HTTP capability access inside the public super-admin domain, used to validate the resource model, executor path, and audit chain
Tenant-side users already have a read-only HTTP-resource ledger showing request summaries, authentication style, and write boundaries for resources they are authorized to view, but self-service configuration and dry runs are not opened to tenants
HTTP resources are still advanced only under a fixed-interface, explicit-authentication, write-whitelist model, and configuration authority plus credential governance remain in the public governance domain
The platform may later support orchestration where one Skill chains multiple scripts or multiple capability nodes together inside rules, but that is a post-2.0 productization direction rather than a finished 1.0 / 1.1 capability

For current use, think in terms of trusted single-Skill execution first. More complex multi-capability orchestration is not yet a completed 1.0 / 1.1 feature. Before formal orchestration becomes a public product line, the platform still needs stronger runtime contracts, node-level confirmation, formal fallback / downgrade behavior, and recoverable partial-success governance.

1.1 In Progress

How far the low-support loop has already landed

The public order center already supports order creation, payment confirmation, activation execution, renewal prefill, renewal-reminder scans, and expiry shutdown scans
The personal free edition already supports lightweight self-service purchases for local script slots, and confirmed purchases refill the current account quota directly
The personal free edition also exposes an upgrade path into the monthly / yearly team edition and routes the user into standard SaaS tenant registration
Customer, order, and tenant status now link back into each other instead of being isolated sample pages
The current purpose is to let the team run the charging and lifecycle chain on its own first and reduce later support-heavy manual follow-up

Still Pending

What has not been publicly promised yet

The platform is not yet presented as a full self-service end-user payment center. What exists today is lightweight local-script-slot expansion for the personal free edition plus an upgrade entry toward the team edition.
There is not yet a real third-party payment gateway with signing and verification.
Renewal reminders are currently platform-side scans and audit traces, not fully automated email / Enterprise WeChat / SMS delivery.

Platform template distribution

Platform template publishing
Tenant-side install request and install confirmation
Version control, rollback, and distribution logs
A foundation for template reuse, delivery review, and stable future expansion

Announcement and log governance

Platform-wide and tenant-specific announcements
Targeting by tenant or user
Read status and read detail
Login logs, operation logs, and platform audit trails

Execution safety boundaries

High-risk actions still require manual confirmation
HTTP write operations are denied by default and must be whitelisted explicitly
Tenant-side users do not see platform-governance pages. They only see authorized execution and read-only entries.
Administrator detection has been tightened. The runtime no longer misclassifies admins using unsafe shortcuts such as user_id == 1.

CLI and local onboarding

login / register / list / run
agent describe / agent start
The significance is not command-line packaging. It is the bridge between the platform control plane and the local environment.

Customer Visible

What customers can actually see today

Login and account usage
A list of customer-specific capabilities instead of raw script source paths
The intelligent-brain conversation entry and the manual execution entry
AI-assisted recommendation with confirmation, execution-result view, file upload, and result download
Platform and tenant announcements
When the user is authorized for HTTP-type Skills, they can view resource summaries, authentication style, and write boundaries in read-only mode
The personal free entry has already formed a continuous usage chain: signup result page, capability library, intelligent assistant, announcement center, community square, personal space, formal-upgrade entry, script upload, read-only HTTP ledger, and lightweight local script-slot expansion

Execution Reality

How customers actually use these capabilities

Manual path: log in -> find the capability -> fill the input -> submit execution -> inspect the result or artifact
AI path: express the request -> the platform recommends capabilities inside the current tenant and permission scope -> manual confirmation if needed -> execute the capability -> return the result
Some higher-risk capabilities still force manual confirmation and do not run as unconstrained automation
AI does not recommend another customer's capability across tenant boundaries

Hot Update

How customer scripts keep getting updated

The customer prepares a script directory that includes at least main.py and README.md
The script is uploaded into the correct tenant directory instead of being mixed into another customer's directory
The platform completes review, sync, script registration, Skill binding, and tenant authorization
After verification succeeds, only the owning tenant can see and use the updated capability

Why It Matters

What hot update actually solves

New or updated scripts do not require redeploying the whole platform
The platform still keeps control over review, registration, and authorization
Other tenants do not automatically inherit a customer's update
This turns continuous delivery into a formal capability instead of a one-off project step

Future Extension

The next important expansion is not “more pages”, but more governable capability types

Public capabilities are still script-first today, but the platform already leaves room for the directions below. This is an expression of platform expansion boundaries, not a promise that everything is already standardized and commercialized. The HTTP API sample has already landed in the public governance domain and validates the onboarding path.

HTTP API / SaaS

Turn third-party interfaces, internal services, webhooks, and external-platform actions into capabilities. The first sample is already in place, but the scope is still kept to fixed interfaces, dry-run verification, and auditability.

Data connectors

Turn database queries, warehouses, and business-system writes into standard entry points.

Document templates

Turn contracts, weekly reports, reports, forms, and standard document generation into reusable services.

Approval flows

Bring process initiation, state lookup, and workflow-node actions into the same permission and audit chain.

Specialized model services

Bring OCR, document parsing, speech recognition, image generation, and similar model capabilities into one governance system.

Ops actions

Continue standardizing inspection, log cleanup, backup, alert linkage, and service checks.

Why These Matter Together

Why this is a system instead of a feature list

ArchitectureIsolation determines whether the platform can handle multiple customers

Without a clear tenant boundary, the platform cannot enter formal customer scenarios or explain its governance story convincingly.

DeploymentLocal bridging determines whether the platform can enter real environments

Many high-value tasks depend on intranets, file systems, and local data, so the story cannot stop at a cloud page.

RoadmapTemplates and audit determine whether delivery can stay stable

Without template distribution, rollback, and log governance, many capabilities cannot be reused reliably or delivered sustainably.

DeliveryCapabilities must turn into real delivery and update flows

The Customer Flow / Delivery page explains how customers use the platform, how the platform delivers it, and how hot updates enter the formal chain.

FilesHow input files and result artifacts enter the formal flow

Many real scenarios do not just return text. They take files in, process them, and return result files under delivery boundaries.

DeliverablesWhat the customer finally receives determines whether a capability is really deliverable

The Deliverables page expands what the customer gets beyond the execution capability itself, including instructions, entries, and long-term usage points.

CLIThe local bridge determines whether real capabilities can connect into the platform

The current register / list / run / agent commands are the first layer that lets the platform enter local environments and onboard script-shaped capabilities.