For agents and technical readers

Validate, approve and publish a View

Build a complete read-only View bundle, obtain independent approval and verify its published route and data as an intended viewer.

Contents

Compatibility and authority

Requires Core 0.20.11, Portal 0.3.47 and the actual View tools on the intended connection. The author needs propose access to the operations bundle area and read access to the source records. Every response is limited by viewer grants, declared aliases and current grants of every author of the installed release.

The author cannot approve their own bundle. Publication requires a different authorised owner or admin with app-operating authority. Use the actual runtime schemas; the generic app-bundle annotation may still describe Python apps while the View contract accepts static files.

Discover and build from the served skill

Call get_skill:

{"name":"view-builder"}

Read its template and referenced View contract through the returned paths. Discover actual zones and source records. Use whole zone roots for aliases and actual subfolders for datasets; do not paste a fictional root from the template. New orient output may omit path roots, so use the returned zone discovery route rather than assuming every orient field exists.

Agree the page, route, datasets and private-data layout. Build every file in memory from the supported template, retaining mind.js. Use textContent for record values, handle empty/partial/truncated responses, and never use sample data as a published fallback.

Validate the complete bundle

Call view_dry_run with files mapping every filename to its full text. This checks contract validity without proposing/installing or proving useful dataset rows.

The static bundle allows up to 40 regular UTF-8 text files, 256 KiB each and 2 MiB in total. It declares no schedule, budget, write verbs or external network access. Dataset limits are 8 sets, 20 fields each,2,000 rows each and 4 KiB per value; treat truncation and partial states explicitly.

Fix the named refusal, then rerun validation. Do not loosen the sandbox or replace the bridge with direct network calls.

Propose one complete bundle

Submit one propose_write containing all files under the actual 26-operations/examples/x-<name>/ directory, with op:create for a new bundle. Use a new lower-case app ID and unreserved single-segment route. The gateway attributes the publisher; do not impersonate another author.

Retain the proposal ID. Held is the expected independent-review state, not an error to bypass. Give the reviewer the complete file set and intended source scope.

Approve, publish and inspect

After the different authorised reviewer checks the exact bundle, call act for each separate lifecycle step:

{"action":"app_bundle_approve","item_id":"<proposal_id>"}
{"action":"app_install","item_id":"x-<name>"}

Replace placeholders with discovered IDs; approval and installation are separate effects. Inspect both results. Call view_resolve for the agreed route:

{"route":"<name>"}

Open the returned route in a browser as the intended viewer and compare sample rows with authorised sources. Check a harmless excluded record and empty/partial data. Tool resolution alone is not visual acceptance.

Upgrade and recover

Read the current complete bundle, raise its version, dry-run and propose all files with op:upsert. A different authorised reviewer approves; act action app_upgrade applies the approved release. Supported actions app_rollback, app_suspend, app_resume and app_remove use item_id as the app ID. Inspect the route and state afterwards.

An unapproved source edit can make a View unavailable. Restore or approve through the supported lifecycle; do not edit the installed tree or permit self-approval. A lost action response requires inspecting the original proposal/install state before repeating it.

Related

Build and publish a team View · Open a team View and check its information · Review changes and check what was saved

Practical guides for people and agents

Start with one useful job

Join the waitlist

Plain text for AI agents. Same content as the human page.

## For agents

- What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC.
- Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up.
- How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link.
- Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents.

---

# Validate, approve and publish a View

Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works)

Build a complete read-only View bundle, obtain independent approval and verify its published route and data as an intended viewer.

[Page as Markdown](https://app.mensara.ai/how-it-works/build-view-procedure.md)

[Human guide](https://app.mensara.ai/how-it-works/build-a-team-view)

## Use the released interface with current authority

Availability: Core0.20.11 / Portal0.3.47 source checked; discover the actual installed client and enabled features.

Who can do this: The connected principal with the permissions named in this procedure

What changes: The procedure explains its actual reads, writes or external effects before action.

Limits: An input accepted by a source schema is not a successful installed-runtime task.; Keep human decisions, client exclusions and pending results explicit.

Verification: Source checked and independently reviewed; scoped runtime receipts are recorded separately.

## Compatibility and authority

Requires Core 0.20.11, Portal 0.3.47 and the actual View tools on the intended connection. The author needs propose access to the operations bundle area and read access to the source records. Every response is limited by viewer grants, declared aliases and current grants of every author of the installed release.

The author cannot approve their own bundle. Publication requires a different authorised owner or admin with app-operating authority. Use the actual runtime schemas; the generic app-bundle annotation may still describe Python apps while the View contract accepts static files.

## Discover and build from the served skill

Call `get_skill`:

```
{"name":"view-builder"}
```

Read its template and referenced View contract through the returned paths. Discover actual zones and source records. Use whole zone roots for aliases and actual subfolders for datasets; do not paste a fictional root from the template. New orient output may omit path roots, so use the returned zone discovery route rather than assuming every orient field exists.

Agree the page, route, datasets and private-data layout. Build every file in memory from the supported template, retaining `mind.js`. Use `textContent` for record values, handle empty/partial/truncated responses, and never use sample data as a published fallback.

## Validate the complete bundle

Call `view_dry_run` with `files` mapping every filename to its full text. This checks contract validity without proposing/installing or proving useful dataset rows.

The static bundle allows up to 40 regular UTF-8 text files, 256 KiB each and 2 MiB in total. It declares no schedule, budget, write verbs or external network access. Dataset limits are 8 sets, 20 fields each,2,000 rows each and 4 KiB per value; treat truncation and partial states explicitly.

Fix the named refusal, then rerun validation. Do not loosen the sandbox or replace the bridge with direct network calls.

## Propose one complete bundle

Submit one `propose_write` containing all files under the actual `26-operations/examples/x-<name>/` directory, with `op:create` for a new bundle. Use a new lower-case app ID and unreserved single-segment route. The gateway attributes the publisher; do not impersonate another author.

Retain the proposal ID. Held is the expected independent-review state, not an error to bypass. Give the reviewer the complete file set and intended source scope.

## Approve, publish and inspect

After the different authorised reviewer checks the exact bundle, call `act` for each separate lifecycle step:

```
{"action":"app_bundle_approve","item_id":"<proposal_id>"}
```

```
{"action":"app_install","item_id":"x-<name>"}
```

Replace placeholders with discovered IDs; approval and installation are separate effects. Inspect both results. Call `view_resolve` for the agreed route:

```
{"route":"<name>"}
```

Open the returned route in a browser as the intended viewer and compare sample rows with authorised sources. Check a harmless excluded record and empty/partial data. Tool resolution alone is not visual acceptance.

## Upgrade and recover

Read the current complete bundle, raise its version, dry-run and propose all files with `op:upsert`. A different authorised reviewer approves; `act` action `app_upgrade` applies the approved release. Supported actions `app_rollback`, `app_suspend`, `app_resume` and `app_remove` use `item_id` as the app ID. Inspect the route and state afterwards.

An unapproved source edit can make a View unavailable. Restore or approve through the supported lifecycle; do not edit the installed tree or permit self-approval. A lost action response requires inspecting the original proposal/install state before repeating it.

## Related

- [Build and publish a team View](https://app.mensara.ai/how-it-works/build-a-team-view)
- [Open a team View and check its information](https://app.mensara.ai/how-it-works/team-views)
- [Review changes and check what was saved](https://app.mensara.ai/how-it-works/changes-approvals-receipts)

[Join the waitlist](https://app.mensara.ai/#waitlist)