Explore all capabilities

Define authentication requirements for the organization types your application serves. Wildo combines those application-authored requirements with the person’s account policy when they sign in.

A person can stay signed in for everyday work and still prove their identity again before a high-impact action. Wildo connects the operation’s requirement to a fresh authentication challenge and resumes the action after verification.

Offer a short-lived code sent to a verified phone when that method fits the account policy. Wildo connects phone verification, delivery limits and code checking to the normal authentication flow.

Support a customer’s SAML identity provider without rebuilding the sign-in and account-linking flow. Wildo validates the returned assertion and connects it to the intended organization’s account policy.

Withdraw a person’s existing tokens across devices when they sign out everywhere or a credential needs to be replaced. Wildo checks the revocation state during token use and refresh, rather than waiting only for normal expiry.

Use a token for a specific interaction: accepting an invitation, resetting a password, carrying a redirect or granting bounded access. Wildo records its purpose, expiry and allowed use, then checks those conditions when it is redeemed.

People can read their own account and choose to deactivate it through a dedicated self-service surface. Wildo keeps these actions separate from the administrative operations that manage other users.

Signing out should not leave another tab looking active. Wildo tells the application’s other same-origin tabs to clear their authentication state, API credentials and live connection.

Keep people signed in without treating a long-lived token as permanent authority. Wildo refreshes access through rotating credentials and checks the account’s current state before continuing the session.

Offer an external provider as a way into the application. Wildo handles the redirect, callback and identity linking, while the application keeps its own account and membership model.

Give administrators named actions for changing roles, suspending access and restoring accounts. Wildo carries those actions through their permissions, account transitions and audit behavior.

An authorized administrator can create a time-limited link for a specific person’s account, for support or a supervised walkthrough. Wildo checks the target’s eligibility and bounds the resulting access.

Let people replace a forgotten password using an expiring email link. Wildo checks the replacement against the account’s policy and withdraws earlier tokens when the change completes.

An administrator can initiate a password reset for another account, withdraw its existing sessions and send the replacement link to the account owner.

Add a second proof to sign-in for the accounts that need it. Wildo connects the policy, enrollment, challenge and recovery-code flow, so people are offered methods the application will actually accept.

Members and administrators do different work and carry different responsibility. Give each kind of account its own password requirements, failed-attempt policy and enabled sign-in methods.

Give people a passwordless route through their inbox. Wildo sends an expiring link, verifies it and continues the account’s normal authentication requirements.

Let people use a passkey instead of remembering a password. Wildo handles the challenge, credential enrollment and sign-in verification, and keeps passkeys attached to the person’s existing account.

Connect an organization’s identity provider through OpenID Connect. Members use the customer’s sign-in process, while Wildo connects the verified identity to the application’s account and membership rules.

Roles describe what a person or service may do. Wildo lets your application extend the built-in roles and inherit their responsibilities, so you can express your own team structure without rebuilding ordinary access checks.

An administrative change should not leave the application with nobody able to manage it. Wildo refuses changes that would remove the last usable super-administrator and explains the recovery step.

Organization-owned records are confined through the framework’s resource and repository paths. Application code can work with the current organization’s data without rebuilding a tenant filter in every endpoint.

People can delegate responsibilities they hold without being able to create a more powerful account or integration. Wildo checks requested roles when members and machine credentials receive their authority.

Each customer can have its own supported identity, provisioning and audit connections. Wildo places those settings in organization-owned resources so one account’s configuration does not become the application-wide default.

A referenced person or organization can exist without being eligible for this record. Wildo can require the declared membership or partnership before accepting the link.

Support access can be tied to one customer account, a written reason and an expiry instead of being a standing privilege. Wildo requires a usable grant for declared platform crossings and lets the customer require approval.

Some information belongs to the application, some to a customer organization, some to one person and some to a visitor who has not registered. Wildo makes that ownership an explicit part of the resource definition.

A refusal should not reveal whether another customer’s record exists. Wildo separates the decision visible to the caller from the detail needed to investigate the refusal.

Account lists need their own boundary: an organization record is the account itself, rather than a record carrying a parent account ID. Wildo confines those collections to the caller’s organization-wide memberships.

An authorized write must remain in the account it was authorized for. Wildo reconciles the caller’s identity, addressed scope and server-managed ownership fields so request data cannot quietly move the operation into another tenant.

Bring someone into an organization with a defined membership and role. Wildo connects the invitation, account and acceptance flow, whether the person is new or already uses the application.

Let a customer’s directory provision people into its organization and manage their membership there. Wildo connects those changes to local accounts and configured organization-unit assignments.

A person can use an external identity without becoming a different application user each time. Wildo records the link between the provider’s identity and the local account.

Let visitors begin useful work before they create an account. When they register, Wildo can move the eligible records to their authenticated identity instead of making them start again.

Choose who may create an account, which signup methods they can use and when email ownership must be proved. Wildo carries that policy through account creation and the next step into the application.

Connected tools need a way to discover the application, request authorization and exchange credentials for tokens. Wildo provides those related endpoints as one authorization-server surface.

A service can use its own scoped, revocable access key instead of a person’s password. Wildo ties the credential to its roles and organization or application, with lifecycle actions for rotation and withdrawal.

A person can authorize a connected tool to act through a particular agent endpoint without sharing a full application session. Wildo binds the token to that destination and retains both the person’s identity and the requesting client’s attribution.

A tool without a pre-created client ID can register before starting a user-approved connection. Wildo offers this as an application choice, with limits on what an unauthenticated registration can obtain.

Automated work can belong to a service rather than impersonating a person. Wildo gives registered clients their own scoped roles and tokens, so the application can authorize and attribute machine actions explicitly.

A short-lived, single-use grant authorizes one upload to a specific resource field through the existing upload route.

A tool can identify itself through an HTTPS metadata document instead of requiring a manually created client record. Wildo checks that published identity and applies the application’s trust policy before using it.

A person can choose to remember an approval so a familiar tool does not ask the same question every time. Wildo remembers the client, target and approved identity scopes together, with an expiry.

People can see which application is asking, which destination it will return to and what identity information it requests before they approve. Wildo connects that decision to the pending authorization request.

Give a member a role in one part of the organisation without granting it everywhere.

Keep company information and branding together, ready for the application surfaces that present the customer.

Keep each customer’s people, settings and business records together in an organisation.

Manage a person’s roles and access state separately for every organisation they join.

Use unit roles to grant access to the relevant records while preserving authorised organisation-wide access.

Let people choose the record they are working within from the application shell.

Set language and regional conventions for an organisation while respecting the choices members are allowed to make.

Switch organisation from the user menu, reset navigation and update the live connection without reloading the page.

Represent a customer’s internal structure without creating a separate tenant for every team.

Route organisational email categories to shared addresses and choose which categories are enabled.

Define kinds of organisation and connect their creation to the right registration or administration flow.

Purge organisations after their recorded recovery deadline through the normal resource deletion lifecycle.

Refuse membership changes that would leave an organisation without anyone able to administer it.

Close access first, retain the organisation for recovery, then let the configured purge finish the lifecycle.

Stop an organisation’s authority while keeping its records available for recovery.

Put an explicit identity check in front of the administrator action that bypasses the recovery period.

Give an existing usable member ownership through a narrowly scoped platform recovery action.

Attach email notifications to the organisation actions that affect access and recovery.

Read the customer’s account, subscription, catalogue, invoices, usage and credits together. The shared billing context keeps standard components and custom screens working from the same scoped state.

Describe plans, add-ons and one-time products alongside the features and limits they grant. Wildo turns those definitions into its billing catalogue, so the offer and the application behavior have a shared starting point.

Keep the selected plan, add-ons, trial dates and cancellation state together. Wildo connects customer actions with the provider and updates local subscription records as provider events arrive.

A billing account connects an organization or person to its provider customer and financial activity. Subscriptions, invoices, usage and credits can then refer to the same customer without mixing personal and workspace purchases.

Application billing speaks one shared contract for customers, purchases and subscription changes. A provider adapter translates that contract into the vendor’s API, keeping vendor-specific request shapes out of everyday application code.

Workspace and personal billing use distinct scoped accounts and records. Wildo checks the account behind a request and resolves provider events back to that account, so a purchase stays with the customer it belongs to.

Closing a customer account should not scatter its financial history. Wildo retains the billing records and their account relationships, so invoices, subscriptions and usage remain attributable after the owning workspace is removed.

Bring provider invoice status and totals into the application’s billing history. Wildo stores a scoped reference to each invoice while the billing provider remains responsible for the document itself.

Open the billing provider’s customer portal from the application. Customers can use the provider’s configured tools for payment methods and billing documents without your application handling card details.

Bring provider payment activity back into customer billing state. Wildo verifies incoming events, identifies the billing account and updates the corresponding subscription, invoice or completed purchase.

Choose whether hosted checkout asks the provider to calculate tax, and declare whether each price includes tax. Wildo passes those choices to the billing provider instead of calculating tax locally.

One-time items and credit packs use the same billing provider and hosted checkout as subscriptions. Selecting a separate payment vendor independently of subscription billing is not an available configuration.

Attach recurring or one-time prices to a product, with their currency and pricing model. The product defines the offer; its prices define how the customer pays for it.

Coordinate provider subscription cancellation, customer scrubbing and payment-method detachment while preserving invoice continuity.

Put trial, cancellation and price-adjustment decisions next to the product they govern. Wildo applies the supported settings when opening checkout or changing a subscription, while provider-managed collection settings remain with the provider.

Let customers choose an offer in your application and complete payment with the billing provider. Wildo checks the selected product and price, creates the provider session and connects completion to the right billing account.

Choose whether your application sells subscriptions or purchases, which provider handles them and whether the customer is an organization or an individual. Billing activation connects those decisions to the application’s billing resources and services.

Wildo’s Stripe adapter connects application billing to provider customers, prices, checkout, subscriptions and invoices. Your application keeps its product definitions while Stripe handles the hosted payment experience.

Connect discount rules, provider coupons and completed checkout redemptions.

Separate product packaging from the features and allowances your application checks.

Use feature availability to show an appropriate next action, hide an unavailable surface or guide the person to an administrator.

Add purchased credits to a scoped balance and consume them through trusted backend operations.

Give a customer specific feature or allowance overrides without changing the catalogue.

Each customer can have its own supported identity, provisioning and audit connections. Wildo places those settings in organization-owned resources so one account’s configuration does not become the application-wide default.

Keep grants, allowances and manual exceptions in explicit records for each owner.

Make customer eligibility, administrator access and integration setup separate decisions.

Use the framework’s named feature definitions alongside your own commercial offering.

Combine application, customer and individual feature settings without confusing their ownership.

Give customers a billing home composed from shared subscription, plan, usage and invoice widgets.

Keep both accounts, conversion state and promised rewards in one referral record.

Record operation quantities locally, then report them to the billing provider.

Personalized messages can use the recipient’s name, email and language without repeating profile lookups in every template. Wildo assembles that context separately for each recipient.

Email templates receive shared colors, typography and spacing values. Components can use those values to keep account messages visually related to the product.

Keep application messages independent of the company that delivers them. Choose an email provider through configuration while preserving the same templates and notification declarations.

The development companion provides tools for generating template files, translating labels and previewing rendered messages. Work stays in the application’s source files, where it can be reviewed with the rest of the product.

Use the normal application email flow during development without contacting a recipient. The preview provider renders the message and makes its subject, recipients and content available in local logs.

Reuse headers, buttons, body text and footers across email templates. A shared layout gives messages a recognizable structure while each template keeps its own purpose and content.

A logical email submission has an identity that can be reused when delivery is retried. Supported providers can recognize that identity, reducing accidental duplicate submissions after an uncertain response.

An email specification explains its purpose, tone, required information and the role of each text slot. People and coding assistants can change the wording while preserving what the message must accomplish.

Write email layouts and behavior in React alongside the application. Templates receive typed labels, brand values and message context, so account and business emails can share the same design without duplicating their content.

When an operation notifies a larger group, Wildo queues the per-recipient emails instead of sending them all on the request path. Each message keeps its own language, context and submission result.

Keep one email layout with separate language files. Wildo resolves recipient language and available labels, then falls back through configured alternatives when an exact locale is unavailable.

Account links, receipts and business notifications use a shared sending path. Wildo renders the message, hands it to your configured email provider and records whether that provider confirmed acceptance.

Promotional messages can select a different provider capability from account and business email. The distinction is made on the template, keeping delivery routing explicit.

Wildo names recurring account and security messages and provides their template contracts. Your application can customize their wording and appearance without inventing a separate identity for every message.

Wildo supplies adapters for established email providers, so selecting one does not require rebuilding message formatting, authentication and response handling.

Declare who should hear about an action and how they should hear it alongside the action itself. Wildo resolves recipients and dispatches the configured notification after the operation.

When an operation issues an acceptance or recovery link, Wildo can create its token in the same transaction as the record change. The email then uses that token to point at the declared action.

When records change, Wildo can notify connected views so they refresh the affected information. Shared live-update handling connects backend operations with lists and record screens.

Choose whether a badge shows a number, a simple dot or nothing. Its attention behavior can be quiet, briefly react to an increase or remain active while work is waiting.

Send an operation email to an address stored on the record, even when its recipient has no existing user session or profile. This supports invitations and other messages whose destination is known before registration.

People can choose their notification channels. Wildo applies those preferences to personal notifications while keeping role-addressed responsibilities and explicitly required notices distinct.

Use the request, the resulting record and the operation context to decide whether a message belongs. One action can notify in one situation and stay quiet in another.

Route organisational email categories to shared addresses and choose which categories are enabled.

Derive a navigation badge from the records it represents. Wildo counts the matching data for the person or organization and refreshes the count when the source changes.

Attach email notifications to the organisation actions that affect access and recovery.

Send an operation message to connected users without waiting for a page reload. Wildo carries the message through the live connection and into the application’s notification presentation.

Use a stored badge count for information that the counter itself owns, such as arrivals waiting to be acknowledged. Operations can increase, decrease or reset it.

A field declares an ordered set of allowed storage destinations; new uploads use the first configured match.

Carry field erasure into attached files and scrub the file record’s own identifying values.

Application and platform service identities obtain renewable, prefix-confined storage sessions through their respective credential channels.

A frontend provider supplies reusable picker defaults while individual fields keep their own requirements.

Managed and local storage compose the normal file path from application, resource and owner scope before adding the field’s chosen name.

Google Drive can supply an existing file reference or receive an upload through the connected user’s delegated access.

An internal file record tracks storage, ownership and lifecycle separately from the bytes and the parent record’s small file reference.

Required scans block downloads and new attachments until a clean result. Standard forms wait while the file is being checked.

File handling follows supported nested objects and repeated items, so attachments can stay inside the record structure that gives them meaning.

The local provider uses the same file lifecycle while storing bytes under a configured directory.

Large queued inputs can be stored in an internal payload resource and referenced by ID, with compression and a finite retention period.

Shared file-serving code sets browser protections and forces active HTML, XHTML and SVG content to download.

The managed provider stores bytes separately from records and obtains application-confined session credentials for storage access.

Services and scheduled batches can write artifacts through the same configured storage providers without a browser upload.

An image field’s aspect ratio can activate cropping and resizing inside the standard upload control.

A short-lived, single-use grant authorizes one upload to a specific resource field through the existing upload route.

The resource’s file route checks read permission, the file’s exact record-and-field binding, and its own scope before serving bytes.

A file field connects upload, record attachment and authorized access through the resource that owns it.

File metadata records an optional uploader ID and principal type derived from the authenticated execution context.

Record changes mark files for the chosen lifecycle, and a cleanup batch removes abandoned uploads and expired deleted files.

Fields can allow a file-specific bearer token with an expiry and a bounded number of completed uses.

Eligible images can be resized when served, keeping one stored original and the same authorized file access path.

Keep a field’s file types, size and media requirements beside its definition, where browser and backend can read them.

Design a PDF template around a resource and let creation attach the rendered document to the record.

Choose which file fields contribute to retrieval, how their text is split, and how access to the source records governs results.

Describe a generated document’s output, lifecycle and available data in a specification checked against its resource declaration.

Extract text locally from supported PDFs, text files and modern Office documents, ready for processing and retrieval.

Regenerate an attached PDF from the current record through a dedicated action, keeping ordinary edits separate from document publication.

Connect a document-recognition provider for file fields that need to read scans, with explicit processing choices and local fallback.

An optional verified ledger adds an integrity check beside the application’s audit store. Wildo can send events to immudb, retain a verification anchor and reconcile missed writes using the same event identities.

Wildo carries available request correlation into audit events, logs and errors. Investigators can follow the effects of one action without reconstructing the sequence from timestamps alone.

Wildo classifies security events with a shared category and severity. A sign-in, a permission change and an access refusal retain their different meanings as they move from the application’s trail into a customer’s security tooling.

Wildo turns sign-in activity, access decisions, administrative changes and recorded disclosures into structured evidence. Each event can be searched and connected to the actor, subject and request that explain it.

Wildo can copy older audit records into dated JSON artifacts in object storage. Your operational trail remains available, while a separate archive supports longer-term review and controlled handover.

An event’s subject and its delivery destination are different facts. Wildo keeps customer viewing and security-event delivery tied to the appropriate scope, so a customer identifier inside event data cannot choose where that event is sent.

Account deletion should not erase the explanation of what happened. Wildo records completed user and organization deletion using the pre-deletion subject details, and keeps audit records outside the organization’s deletion cascade.

Wildo distinguishes a person, a machine, the application itself and an action whose actor could not be resolved. Automated work stays recognizable in the same trail as human activity.

Customers can read, filter and export their audit records through the application’s resource interface. The same declared contract supplies the standard screens, access rules and API reference.

High-impact resource changes produce an audit event through the shared operation path. Wildo records the action, its subject and the fields changed, so evidence follows the operation instead of depending on a separate logging call in every handler.

When the standard resource response reveals a marked one-time credential, Wildo records the disclosure: who received it, which field was shown and which record it belonged to. The evidence contains the fact of disclosure, not a second copy of the credential.

Authentication rules authored in configuration deserve the same visibility as settings changed through a screen. Wildo records the baseline and changes to the deployed authentication posture, including affected user types and before-and-after values. Changes to the application audit-reading policy are recorded too.

Customer security collectors can become unavailable without stopping the application. Wildo queues delivery, retries failures and retains exhausted deliveries for an administrator to inspect and replay.

An access refusal can be valuable security evidence. Wildo records authorization denials with the attempted operation, required authority and classified reason, while grouping repeated attempts into an escalating series.

Each customer can configure a destination and choose the security events their team needs. Wildo applies that organization’s delivery settings around a shared event contract, so customers can use their own monitoring and review workflows.

Wildo projects the same security event into structured JSON, CEF, LEEF or OCSF. Customers select the format their collector accepts while retaining a common source for the event’s meaning.

Assemble a purpose-specific data bundle from declared resources, with a report explaining its contents and exclusions.

Run registered external erasure effects after local changes and return an actionable outcome for each service.

Connect erasure to the right sign-in principal instead of guessing from a foreign key.

Carry field erasure into attached files and scrub the file record’s own identifying values.

Distinguish information supplied by a person, observed through use and derived by the application when assembling portable data.

Declare an expiry instant or age window and connect it to scheduled record removal.

Record consent as a set of independently granted purposes, ask for it instead of assuming it, and keep optional processing off until it is given.

Apply the same retention boundary to ordinary reads, updates, counts and aggregate results.

Declare the kind of personal data at the field so the application inventory can describe its contents precisely.

Present the requesting client and requested access before completing user-authorized delegation.

Coordinate provider subscription cancellation, customer scrubbing and payment-method detachment while preserving invoice continuity.

Coordinate deletion and declared field scrubbing while keeping retained records hidden and frozen.

Provide a privileged, scoped read of retained records whose disclosure must itself be recorded.

Record the processors involved in an application’s delivery, including legal identities, processing regions and disclosed subprocessors.

Stable control references connect assurance objectives to their implementation, making technical review and change impact easier to follow.

A shared objective catalogue connects application commitments to the capabilities, implementation and evidence they depend on.

Required scans block downloads and new attachments until a clean result. Standard forms wait while the file is being checked.

Evidence requirements identify the artifact and execution context that can support a control, so reviewers know what to inspect.

Declare where an application operates and why, then compare that reach with the sources available to its assurance and document workflows.

External mappings connect Wildo objectives to cited sources while keeping runtime behavior independent of changing assessment terminology.

Keep the operator’s identity, processing roles and declared purposes in configuration so documents can use a consistent account of the business.

Generate a portable knowledge package containing source-derived references, authoring guidance, playbooks and the assurance basis used by application tooling.

The creation workflow separates research, evidence evaluation, product facts and document drafting, keeping each step accountable to the information it needs.

Separate reusable document facts from the prose that cites them, so a statement can be reviewed against what the application has actually declared.

Declare exact language and jurisdiction combinations so public-document preparation follows deliberate audience choices.

Introspection reads resource declarations directly, giving document workflows a concrete account of data categories, erasure treatment and declared rights mechanisms.

Compose structured notices and terms from declared facts, required concerns and explicit source references, ready for meaningful review.

Describe the kind of work an agent performs and resolve a suitable model within its chosen provider.

Declare available language-model providers once, then give each agent a provider and a clear job.

Retrieve attributable passages from selected resource fields and documents using the caller’s access context.

Give image generation its own provider configuration and return image assets through the agent runtime.

Maintain derived passages and embeddings as records, ownership and retrieval declarations change.

Extract text locally from supported PDFs, text files and modern Office documents, ready for processing and retrieval.

Dispatch a coding task with an explicit provider, execution profile and workspace policy.

Choose an embeddings provider independently of the provider that generates an answer.

Audio and video are reserved extension points, separate from executable text, image and coding operations.

Start with a conversation screen, then compose richer assistant surfaces from shared components.

A separate graph model describes triggers and steps; conversational assistants run through actor systems.

Stream answers as they arrive and retain the conversation in the application.

Pause a selected write, review its proposed arguments, and continue after a person approves or refuses it.

Give the assistant selected resource operations, executed with the caller’s identity and the operation’s own rules.

Agent integrations need more than a successful demonstration. Wildo’s test scenarios exercise tool and conversation entry points with wrong audiences, foreign records and unauthorized requests, alongside permitted controls.

Outside agents can generate bursts of requests and sustained model usage. Wildo treats them separately: an owner-based throttle controls request bursts, while an optional tenant budget checks accumulated A2A token consumption.

An integration can reconnect to a task’s updates or register a callback for progress. The work remains addressable by its task identity, so the connection does not have to stay open for the whole process.

One application can offer separate tool collections and agent identities for different jobs. Each has its own address and token audience, so integrations can discover a focused surface and keep their credentials tied to it.

Assistants do not all update together. Wildo’s MCP endpoint selects transport behavior for the revision used by each request, allowing supported clients to share the same application endpoint.

An assistant should discover actions it can meaningfully attempt. Wildo filters exposed operations through the resource, route, implementation and server-membership rules before advertising a tool.

An assistant can request a short-lived upload link for a file field, then attach the uploaded file to a record. The document’s bytes travel through the upload path rather than through tool-call arguments.

An outside agent can ask your application for help through a persistent conversation. Wildo routes the request to an exposed actor system and carries the caller’s identity into its work.

Outside assistants can discover and call selected application actions as tools. Wildo derives their input contracts from resource operations, keeping the integration connected to the same business definitions.

Model calls can leave a consistent trace of usage, timing and outcome. Wildo supplies a structured-log destination and can forward traces to a selected observability provider.

Integrations can request cancellation of a running agent task, even when another server replica is executing it. Wildo also tracks task liveness so interrupted work can be recognized rather than appearing to run forever.

Agent clients can use different wire vocabularies while reaching the same application behavior. Wildo translates supported A2A method names and response shapes at the transport boundary.

A configured documentation site can receive a sign-in handoff from the application. It holds a short-lived session for participating documentation interactions while the application remains the owner of authentication.

A documentation portal brings product guidance and an exact API reference together. Wildo derives the managed material from framework-authored guides and application declarations; your application owns the portal’s identity and published contract.

The authoring guide asks the coding agent to start with the reader’s task and verify the product facts behind every instruction. It turns source knowledge into guidance for customers and administrators rather than a tour of framework internals.

Guide claims can point to admitted sources and projected application facts. Publication checks that those references are meaningful for the application before turning them into public material.

The API contract is derived from the application’s resolved resource operations and authored specifications. That connects endpoint descriptions and request shapes to the mechanisms integrations actually call.

A guide can point to a resource, operation, request or response without hard-coding a generated URL. Publication resolves the semantic target against the reference the application actually emits.

Group API resources by the work they support, with names and descriptions readers can recognize. The engine supplies groups for its own resources; the application names the concepts only it understands.

Turn the accepted documentation bundle into pages, navigation and search data that belong together. Managed output checks catch missing destinations and malformed artifacts before the portal consumes them.

The reference distinguishes ordinary application operations from operations reserved exclusively for administrators of the application itself. Readers can focus on the contract relevant to their work.

A real screenshot can make a guide’s instructions easier to recognize. The documentation asset contract distinguishes captured product imagery from a provisional placeholder, so an unfinished capture is not mistaken for proof of the interface.

Reusable guides explain common application behavior such as access, administration and integrations. Application facts adapt those guides so the reader sees the product they are using, rather than an unrelated framework manual.

An orientation, a how-to and an API reference answer different questions. Documentation identifies its purpose and intended readers so administrators and integrating developers can find the depth they need.

A campaign or audience page can reuse the product’s shared story while changing the proof, language and call to action. Give that variation an explicit identity and a reason to exist.

Check the structured information your pages emit against the catalogue that describes it. Findings identify the page and entity that need attention, so invisible metadata receives the same review as visible content.

Keep your sitemap, crawler instructions and indexing policy tied to the site configuration. Public launches and preview environments can make different publication choices without maintaining separate hand-written policy files.

Sections can publish structured descriptions of products, offers and other content alongside the visible page. A shared catalogue defines the supported entity contracts, while the application supplies its own factual values.

A page section can have its own markup and layout while declaring the words and structured information it needs. Wildo checks that contract without prescribing a stock landing-page design.

Use the brand brief to generate and review visual candidates before choosing an accepted identity. Separating exploration from acceptance keeps an unfinished experiment from becoming the product’s public mark.

Page titles, descriptions, social previews and language links come from the page’s declared metadata and the site’s shared address. This keeps the public identity of a page connected to its content.

A shared brand declaration records the name, visual direction and accepted assets. Application screens, public sites and other participating surfaces can select suitable versions from that common identity.

Application-facing guides teach the coding agent how to add pages, sections, navigation and discovery metadata using Wildo’s actual website contracts. They give implementation work a consistent starting point while leaving the product story and design to you.

A public website introduces the product before someone enters the application. Wildo provides the page, language and configuration contracts; you author the story, sections and visual experience.

Publish a plain-text introduction and useful links at `llms.txt` for tools that choose to read it. You control the description; Wildo supplies the serving policy.

A logo needs more than one file: small icons, header compositions and sharing images have different constraints. Derived assets keep their relationship to the accepted source while declaring where each version belongs.

After a brand is accepted, distribute its files and references to the application’s participating front ends. This turns an approved asset set into the images each serving surface can actually load.

A website form can create a real application record rather than leave an enquiry in a disconnected mailbox. An anonymous visitor identity lets participating capture flows retain their connection when that visitor later creates an account.

Apply a supported action to selected records while keeping the target separate from the values being changed.

Declare how owned records are deleted or retained when their parent is removed.

Expose work through the interface, a schedule or an internal call with an explicit contract for each entry point.

Name actions such as assign, approve or ask, declare their contracts and permissions, and add application logic at the appropriate execution phase.

Organize related resources, behavior and screens as a module the application can assemble.

Share the common fields of a business object while defining what changes for each variation.

Define field types, accepted values and shared metadata once; let API contracts, standard forms and storage consumers build on those definitions.

Describe ownership and references so connected records behave according to the relationship they actually have.

Declare identifiers, indexes and uniqueness alongside the values they govern.

Produce the API reference from registered operations and their request and response contracts.

Explain what a resource and its fields mean in a specification connected to their declarations.

Model memberships, dependencies and other meaningful connections as records with their own fields.

Derive nested API routes from the relationships between records.

Choose the everyday actions a resource needs; Wildo supplies their shared execution machinery, with contracts and policies connected to the resource.

Synchronize selected source fields into local resources while preserving the fields your application owns.

Keep the same resource model while PostgreSQL or MongoDB provides its storage through the shared repository layer.

Declare server-only values, masked secrets and write restrictions beside the fields they protect.

Declare whether a resource is retained, how its personal values are treated and how retained rows leave ordinary use.

Present application structure as read-only resources derived from the system that knows it, without maintaining a second catalogue.

Declare initial and maintained records with a stable identity, a trigger and an explicit policy for later runs.

Use the resource’s field definitions to validate operation inputs and return errors that identify what needs correcting.

Define useful filters, text search, sorting and page sizes on a collection operation, alongside its access rules.

Send resource changes to connected views through authorized subscriptions, helping people see updates without repeatedly refreshing.

Give a visitor private working records, then carry that work into an account according to the resource’s transfer policy.

Read an external catalogue or business record through Wildo’s resource interface while its source system keeps ownership of the data.

Offer CSV or JSON downloads from a declared list or search, using that operation’s filters, order and access scope.

Check unique fields while a person fills in a form, using the same declared scope as the stored constraint.

Compose resource surfaces and charts into a workspace that shares their context.

Use feature availability to show an appropriate next action, hide an unavailable surface or guide the person to an administrator.

Arrange labels, help, errors and groups consistently without rebuilding every control.

Compose standard browsing, reading, creation and editing surfaces around the operations your application exposes.

Combine introductory content, contextual guidance and recorded milestones without treating them as the same thing.

Connect validation feedback to the field that needs attention, including errors returned by the server.

Anchor a rich interaction to a record and open related operations without losing its local working context.

Reconcile resource changes and reuse read results only while live subscriptions cover their scope.

Compose conversation, prompt and execution feedback surfaces around a configured assistant runtime.

Replace one operation’s presentation or build an independent screen while choosing which framework behaviors to retain.

Give customers a billing home composed from shared subscription, plan, usage and invoice widgets.

Opt fields into automatic saving on existing records, with validation and visible save feedback.

Give a field distinct reading and editing presentations while retaining its underlying value and constraints.

Drive a navigation badge from a declared count of matching records instead of maintaining a separate counter by hand.

Build create and edit forms from operation fields, then shape the layout without rewriting their validation and submission.

Define a measure once, execute it against scoped records and present it as a chart or dashboard.

Use shared viewport and input signals to adapt layouts and navigation for different devices.

Reuse shared focus, labelling and interaction behavior when composing application screens.

Apply a component theme across shared controls while preserving their application contracts.

Keep component purpose, props, presets and examples in an inspectable specification.

Resolve user-visible labels from structured language bundles across resources and components.

Configure shared colors, spacing and surface tokens, with distinct values for light and dark appearances.

Generate each browser surface’s content-security policy from its configuration and environment.

Share container behavior for layout, focus and content instead of leaving each child to guess.

Generate and translate language files using the application’s declared resources, components and specifications.

Replace a registered component while keeping the screens and contracts that use it.

Use supplied controls and layouts that share the application’s styling, labels and interaction contracts.

Configure the sidebar, command palette and shared controls; let modules contribute destinations without rebuilding the application frame.

Resource routes and breadcrumbs follow declared operations and relationships, while navigation distinguishes a new destination from a change within the current screen.

A shared selector shows the record you are working inside and keeps that selection aligned with scope-aware routes and lists.

Shared keyboard registration, scoped dispatch and a help dialog keep shortcuts discoverable and tied to the active interface.

Switch organisation from the user menu, reset navigation and update the live connection without reloading the page.

Choose when an operation becomes a page, an adjacent pane or a dialog, with responsive rules shared across the application.

Arrange the supplied settings destinations into a clear home, with visible sections adapted to the current person and workspace.

Some integration needs should use one provider. Others, such as additional audit destinations, need every configured destination to receive the event. Wildo records that distinction in the capability itself.

Configuration tooling discovers provider contributions and generates the catalogue used while authoring. The editor can offer provider references, capabilities and protocols from that catalogue instead of asking you to remember their names.

Email, model calls, incoming events and REST requests have different inputs and execution behavior. Wildo gives these connection types named contracts instead of treating every provider as an interchangeable URL.

A provider can contribute server behavior and browser behavior without putting them in the same module. The server side owns credential-aware execution; the browser side carries its public configuration and supported browser code.

The framework's email and SMS paths use common message contracts. Provider modules translate those messages into their vendor's request format and interpret the response back into a shared result.

An application need, a provider's abilities and its connection method answer different questions. Wildo records each explicitly, so choosing an email service is distinct from enabling email or describing how that service receives a message.

The application can keep one provider declaration while an environment selects a different primary. Local email can use a non-delivering preview service while the application's default selects a sending provider.

An application can supply a provider of its own instead of waiting for a vendor to join the engine. Its module declares what it offers and which runtime can use it.

Use provider modules for server-side services such as email, billing, models and business APIs. Each module describes its identity, capabilities, protocols and credential requirements.

Browser providers describe the public configuration and code a frontend service needs. Monitoring, analytics, sign-in and other integrations can be enabled for the product, website or documentation surface independently.

Sign-in vendors differ in endpoints, requested scopes and identity fields. Provider contracts describe those differences so the authentication flow can use them without scattering vendor-specific branches through the application.

A name in a capability or protocol vocabulary is not always an executable integration. Reserved entries make that distinction explicit while the available modules describe what can actually be used.

Each provider describes the credentials it needs without putting their values in the module. Runtime configuration supplies the actual material to the processes that use it.

A provider can describe its deployment options and processing regions. The application records which option it actually uses, so tooling can compare the configured choice with the provider’s declared facts.

A provider can name the extra library it loads when used. The backend checks these declared runtime packages and reports missing ones before the capability is first needed.

The vendor catalogue describes API operations as data: request methods, paths, inputs and authentication. Wildo’s executor uses those definitions to call the vendor.

Bind a resource to the Odoo instance your deployment uses, with explicit model, identity and access configuration.

Send a signed diagnostic through the real delivery transport and distinguish remote refusal from a local send failure.

Shared target checks reject unsafe URL shapes and reserved addresses on the outbound paths that use them.

Send signed event payloads with stable delivery identities, retry handling and a customer-visible delivery record.

Declare which resource actions emit webhook notifications, then let the delivery system handle their subscribed destinations.

The notification model reserves a mobile push channel; device delivery is not implemented.

Registered provider webhook contracts supply routes, verification and dispatch into the corresponding capability handler.

Use the configured SMS provider for transactional messages such as phone verification and sign-in codes.

Read records from their source or maintain a local copy, according to how the application needs to use them.

Describe feature intent and relate it to the customer benefits it is meant to deliver.

Define business areas, resource ownership and tenancy before composing their implementation.

Connect the revenue approach and each offer to its audience and intended scope.

Record where an application destination belongs, or why it should remain unplaced.

Record creative direction and connect it to the assets selected for the product.

Connect attributed research, product facts and evidence to the policy decisions the application needs.

Store different kinds of product decisions as structured, referenceable files in the application.

Record the problem, desired improvement and constraints that should guide later product decisions.

Separate reusable document facts from the prose that cites them, so a statement can be reviewed against what the application has actually declared.

Connect customer needs, benefits, features and evidence in reusable product context.

Give each task an intended product, work scope, prerequisites and a reason in the product definition.

State observable requirements and connect them to the increments intended to deliver them.

Run compatible activities side by side within a managed round, while keeping overlapping output work separate.

Reassess available work after each round instead of following a sequence that no longer matches the application.

Connect a method to relevant project facts and guidance without sending every available source to every run.

Describe what a piece of work needs, how it should be done and what it should produce.

Combine research, checks and production so that each next step responds to what the previous work established.

Make the next possible steps visible, with concrete reasons when their inputs are not ready.

Give structured generation the artifact’s contract, then normalize and validate its answer.

Give creation methods explicit product answers before they turn assumptions into proposed work.

Check an artifact’s structure and supported relationships before generated content is landed.

Distinguish how freely work can run from who reviews and accepts its result.

Review competing proposals with explicit criteria, specialist perspectives and recorded revisions.

Compare connected specifications to reveal broken references and goals that have no planned delivery.

Turn product context into reviewable expert charters with explicit priorities and quality standards.

Pause a participating generation step for a product decision, then continue with the answer in context.

Accept product definitions and implementation changes through ordinary Git review and commits.

Evaluate produced work against declared criteria and retain actionable reasons beside each verdict.

Compare collected source addresses with the addresses present in produced artifacts.

An optional brief check can identify a missing declared source and recompose the input once before generation.

Apply an explicit permission policy to the requests a coding agent sends to Wildo.

Serialize managed coding runs and configuration sync so their file changes do not overlap each other.

Investigate external questions in a separate agent lane, with findings collected in the application research store.

Dispatch a coding task with an explicit provider, execution profile and workspace policy.

Compare the workspace before and after a run, keeping earlier edits and uncertain ownership visible.

Bring the task, existing application structure and intended design together before the coding run starts.

Restore a playbook run's recorded files while surfacing later content changes for review.

Developers and coding agents can discover and query the companion’s application views with provenance attached to the answers.

A persistent local companion supplies application context and development services while short-lived commands and the workbench use them.

The companion derives application views from compiled packages, reuses them and refreshes affected views when emitted output changes.

The terminal and workbench reach companion services through interfaces suited to commands and resource operations.

Inspect development work, application structure and results in a local browser workspace connected to companion services.

Inspect the recorded brief, events and answer associated with a creation step when investigating its result.

Compose an application website with its service and workspace registrations, ready for your content and brand.

Compose the portal and connect it to the application documentation publication.

Apply a named composition scenario to create files and register the new piece across the application, with a preview before writing.

Check the links between source topics, references, skills and methods before delivering guidance.

Compile authored methods and extracted contracts into the knowledge package delivered to applications.

Install task-specific guidance that connects a change to the framework contracts and application layers it affects.

Use distinct guides for inspecting development state, choosing work, running it and reviewing the result.

Add pages, sections and locale starting points while keeping their project registrations connected.

Generate each browser surface’s content-security policy from its configuration and environment.

Deliver standing guidance alongside task-specific skills, with managed imports in the application instructions.

Keep examples in compiler coverage and connect executable samples to their runtime tests.

Describe the inputs, guidance and expected result of a development activity in a reusable method.

Generate the source-backed guidance package that applications receive with the framework.

Named source excerpts put actual framework contracts beside the method that explains how to use them.

Derive module and resource composition from the domain plan, keeping resource ownership and tenancy explicit.

Apply a named composition scenario to create files and register the new piece across the application, with a preview before writing.

Refresh environment files, service artifacts and deployment workflows from the same authored configuration.

Read resolved application structure, specifications and coherence from the running development companion.

A persistent local companion supplies application context and development services while short-lived commands and the workbench use them.

Create, configure, run and inspect an application through commands that understand its workspace.

Start an ordered development session, inspect its state and choose between preserving data and starting fresh.

Create the application structure, local configuration and development knowledge together, then build your business features on that shared starting point.

A standalone service that stands in for a customer's identity provider, directory, security-event sink and webhook receiver, so enterprise integrations can be proven end to end without a real customer.

The pieces every test lane needs, from running a scenario to surviving a backend restart, live in one package with no third-party dependencies, so packages that must stay isolated can still share them.

A registry of named scenarios drives a real running application over real HTTP and a real browser, and fails the run if the backend logged anything fatal while they ran.

Standalone doubles for the business systems an application reads data out of, so a data pipeline or a provider operation can be exercised against a real socket without a real business system.

The platform services that manage applications are tested from the host as external systems, on the same substrate the application lanes use and with a fatal-log gate scoped to the platform's own output.

Browser scenarios share one implementation of signing in, and a repository check refuses any browser wait that neither gates on the backend being up nor says in writing why it does not need to.

A standalone service that behaves like an external integration consuming your application's API, so the outward-facing surface is proven from the outside rather than from inside the process that serves it.

Rules that no type system can express are enforced by dedicated checks, each of which can prove it is not broken.

Changes to a relational database are planned, compared against a committed baseline, generated as migrations and applied in order, from the command line.

One command brings a standalone application's dependency versions and declared peers back into step with the framework release it has installed.

The application's visual design is written as configuration, generated into the stylesheet every surface reads, and its brand assets are pushed to each site by one command.

One screen says whether the reference application's development environment is coherent, and a second streams every one of its process logs together.

Releasing the framework is a small set of commands: set the version, sync it across every managed package, publish the packages, publish the image.

A complete, browsable API reference is generated from the application's own resource declarations, with operation names a developer would have chosen by hand.

A reusable piece of an application can be published to a registry and installed into another application, with the downloaded artifact verified against the digest the registry resolved.

A queryable index of every symbol in the repository, so the real consumers of a change can be found across package boundaries in under a second.

The framework can compile a package with either the established TypeScript compiler or the new native one, package by package, with a single switch to roll everything back.

While you work, every package recompiles and republishes itself in the background, and a consumer never sees a half-written build.

Telemetry collection uses a common protocol while its destination and authentication are configured separately. Wildo translates the selected provider’s connection contract into the environment read by OpenTelemetry.

Backend activity can produce connected traces, measurements and log records through OpenTelemetry. Wildo starts the instrumentation before application code and sends those signals to the configured OTLP endpoint.

A selected analytics provider can load its browser SDK through the website’s provider system. Wildo keeps activation, public configuration and cleanup in one integration path instead of scattering vendor scripts across pages.

A selected browser-monitoring provider loads and starts its SDK on the website. Wildo supplies the activation lifecycle and configuration boundary, while the provider supplies the actual error-monitoring integration.

Application logs keep messages, service identity and diagnostic context as separate fields. Wildo adds the current request’s correlation ID when one is available, so related activity can be found together.

React error boundaries replace a failed part of the interface with an error state. Wildo connects that fallback to its shared error context and declared frontend actions, so failures can be handled consistently.

A backend failure carries a named type, message reference and context instead of relying on a free-form exception string. Wildo uses that shared contract to shape the response and guide its handling.

A local OpenTelemetry collector gives development processes a nearby receiver for traces, metrics and logs. Wildo’s Compose generation includes it when telemetry is enabled and the configured endpoint points to localhost.

Client error responses keep the information needed to understand a refusal or correct an input, while internal context is filtered before serialization. Wildo applies a shared rule instead of asking every endpoint to decide what to expose.

Local development labels and captures each service’s output while presenting it in the terminal. Choose structured output when diagnostic tools need to read individual log fields.

Wildo classifies handled errors so routine client conditions do not look like server outages. The boundary that handles a failure owns its log entry, with structured fields and a stack when the level warrants one.

Value moments describe activity that matters to your product, such as first value or an activation step. Wildo matches declared signals and exposes achieved moments for the application to use.

Model calls can leave a consistent trace of usage, timing and outcome. Wildo supplies a structured-log destination and can forward traces to a selected observability provider.

Run a separate background service in always-up or scheduled mode, with explicit application-data access and independent platform permissions.

Record job identity, execution state, timing and errors through the application repository layer for operational investigation.

Wildo can copy older audit records into dated JSON artifacts in object storage. Your operational trail remains available, while a separate archive supports longer-term review and controlled handover.

Queue work through the application service layer, with broker-held retry delays and a place to retain failed messages.

Keep recurring work beside its application contract, while the platform delivers scheduled triggers to the runtime that performs it.

Call a separately deployed worker through authenticated HTTP, keeping application data access in the backend.

Record the scope, version and outcome of data setup, with deliberate reruns and retention that preserves version history needed by later passes.

A platform scheduler reads application schedules and sends signed dispatches to the appropriate application or minion queue; the receiving runtime performs the work.

A shared shutdown sequence stops intake, allows active jobs to drain and runs registered cleanup before exit.

The manager provisions service-specific access and brokers confined storage sessions for registered platform services.

Paginated reads apply an operation-owned ceiling so an oversized page request does not become an unbounded response.

Separate an answering process from ready dependencies, with component status that helps explain a refusal.

Startup diagnostics identify missing or fragile administrative access, with breach evidence and an explicit recovery direction.

A timed overlap lets integrations adopt a new API key or OAuth client secret before the previous one stops working.

Declare request windows per operation or authenticated subject, with quota and retry information for callers.

Describe storage, caching, queues and supporting services as a connected environment with shared configuration and deployment rules.

Choose supported self-hosted or vendor-managed connections per service without putting the hosting decision into business logic.

Keep runtime, service choices and public addresses in one typed environment definition, then derive the deployment and process configuration from it.

Derive workloads, configuration, storage and public routing from the environment definition for Kubernetes deployment.

Separate machine prerequisites from running-service checks, with actionable diagnostics before and after startup.

Derive public routes and certificate requests from the same environment addresses that the application advertises.

Keep each local service’s data under a known application directory, independently of replaceable containers.

Choose between preserving local data while reconciling generated state and deliberately rebuilding an empty environment.

Generate connected service containers from the environment definition, with shared ports, storage and startup checks.

Bring up supporting services and application processes in one supervised local session, with shared output and coordinated shutdown.

Wildo derives backing-service configuration and network membership from a runtime’s declared purpose. A background runtime can receive the services it needs without automatically receiving the backend’s full data access.

Production secret values can stay in the deployment’s secret store while the repository holds configuration. Wildo reconstructs the structured secret inputs from the runner’s environment and uses them to generate the runtime artifacts.

Wildo declares the credential material it manages in one registry. Configuration synchronization can provision missing material while keeping already-provisioned credentials, so an existing environment can acquire what a new framework capability needs.

Wildo turns authored configuration and scoped secrets into the environment each process reads. A backend, frontend or background runtime receives its own generated projection, so configuration does not depend on hand-maintained copies of the same value.

Wildo provisions application credentials and narrows background-runtime material to declared access. Database, queue, cache and storage access can follow the runtime’s responsibilities instead of inheriting a shared platform credential.

On the signed application-configuration route, the manager verifies a platform service against its published public key. The issuer and intended recipient are checked alongside the signature.

Automated repository checks catch specific architectural, dependency and security regressions before they become inherited application behavior.

Derive application version pins and required peer declarations from the framework, then install the resulting dependency set.

The platform image installs the declared production dependency graph inside Linux and selects its platform service at runtime.

Generate each browser surface’s policy for its target environment and keep application artifacts and web-server headers aligned.

Generate a reviewable GitHub Actions workflow from environment and service declarations, then complete the rollout steps for your hosting setup.

The framework publication lane builds amd64 and arm64 variants under one image reference, letting the host select its matching variant.

Organization-wide and unit-scoped role changes produce distinct evidence of the requested and resulting authority, attributed to the actor who changed it.

Each application resolves configuration for its own identity. Wildo combines environment connections with platform-managed metadata and credentials, then applies the application's authored behavior.

Cross-tenant access observations identify the operator, target organization, operation and authorizing grant, separate from ordinary member activity.

Application operators reach a customer organization through explicitly declared operations and a usable grant for that organization.

Register an application with its own identity and service declarations. Wildo prepares its platform records, service access and first application records, then derives the configuration its runtimes need.

Each application has its own product-wide roles and customer-organization roles. Managing one customer account does not make someone an administrator of the whole product.

A platform scheduler reads application schedules and sends signed dispatches to the appropriate application or minion queue; the receiving runtime performs the work.

Applications can share the services that register them, coordinate scheduled work and distribute reusable modules. Each application keeps its own identity and configuration while using the same operational foundation.