# Apps, capacity, and continuity

JMPKit is an ambient web utility. Create a floating app directly with
`POST /api/app11/apps`; keep its management key privately. No entity or
account comes first. Hosting and core resources are included within current
limits. Paid Boost adds priority and capacity, not permission to begin.

## Start, then keep what matters

API creation without timing has no scheduled expiration. Your agent should
choose an online lifetime: usually 30 days if unclear, shorter for an event,
or no scheduled end for ongoing work. Supply hours, days, calendar months,
a future timestamp, or `expiresAt: null` explicitly. Report the confirmed
choice with the link. The agent keeps the editable project locally and
publishes a copy to JMPKit; lifetime controls that online copy, not ownership.

Read and update lifetime at the app's `/api/app11/lifecycle`. A renewal uses
the current revision, an idempotency key, and the desired new deadline.
The same app, resources, and link continue. No payment is required simply
to renew or remove scheduled expiration. Publishing does not renew the app.

At expiry, public content and resource calls stop. Identity, keys, notices,
publication history, and stored data remain; an authorized agent can renew
the same app. There is no automatic data purge in this contract. Retirement
is an explicit permanent stop, not a cloud-data eraser.

Cloud-only Q messages, Path values, uploads, and Machine state need their
own export or snapshot. Local source alone is not a backup of live data.

## Included capacity

Every app starts with **100,000 Boost**, bound to that app with no separate
expiry. Every 30 days from creation, add **25,000 included Boost**, capped
at **100,000**. Quiet periods rebuild the reserve up to the cap; excess does
not bank. Use included Boost first. Refills do not extend lifetime or spend
allocated capacity; paid backing is separate from spending order. Retired
apps do not refill. Read `/api/app11/capacity` for current state.

An agent must explicitly assign additional purchased capacity when that
operation becomes available. Never silently draw from another app, entity,
supporter, purchased balance, or payment method. Aggregate fair-use and
creation limits still apply; many apps are not a workaround.

## Current API support

[App11](/docs/app11.md) implements direct creation, app keys, scoped delegation,
rotation/revocation, revision-checked lifetime changes, retirement, service
notices, and the included balance/top-up ledger.

The ledger reports `metering: accounting-only`: automatic usage-to-Boost
charging, paid checkout/allocation, and a paid-priority scheduler are not
connected by this contract. Existing resource limits remain enforced.
Do not invent conversion rates or claim a purchase has completed.

Pressure-driven hosted-copy eviction, automatic renewal workers, and complete
cloud-data deletion are not enabled. Keep source and exports; no-expiration
is not an unlimited-storage or backup guarantee.

## Agent operating rhythm

1. Fetch current instructions and inspect the existing app before new work.
2. Use sensible defaults; create another app only for a separate project.
3. Test the result, return its link, and state its confirmed `expiresAt`.
4. On return, read lifecycle and `/api/app11/messages`; renew or update the
   same app with the user's authority. Service advice is not permission to
   spend or execute changes.

Lifetime, keys, optional grouping, domain names, and paid priority are separate.
Do not infer app persistence from a prepaid purchase alone. Only report a
confirmed expiration or renewal returned by the service.

Existing apps keep their contracts and do not gain retroactive deadlines.
See [version support and migration](/docs/migration-app11.md). No legacy
sunset date has been announced.