- The registry becomes an MBR vault. `vote()` ends with `checkNeedMBR()` subroutine: if the instance app account is at or below its minimum balance, it inner-calls the registry's new `requestMBR`, which pays it `mbrTopUp` (new global, 5 A, settable via `setMBRTopUp`). Users never pay vote-record MBR, and instances no longer need hand-funding.

- Post-condition, not a threshold. The AVM updates `min_balance` the instant a box is allocated but enforces the requirement only after each (outer) transaction, so the account may sit underwater mid-execution as long as the top-up lands first. However, MBR do is enforced between intermediate states of a group transaction, so a sibling payment later in the same group would be too late.

Nits: `checkNeedMBR()` could sit in more than one place:
- periodVoteCache is always an overwrite, so the call could go before it
- on a re-vote the record write is an overwrite too, so the call could be skipped

Left plain at the end for clarity; the saving would be a handful of opcodes. What is not flexible is that it must stay after the vote record write - that write is the allocation it repairs.

pnpm audit --audit-level=high was failing on:

- nanoid <3.3.18 (GHSA-2v37-7h3g-55p8, "custom generators can loop
  indefinitely when size is zero") -> 3.3.17 bumped to 3.3.18

nanoid is only in the tree transitively via postcss (>vite>vitest etc.),
whose ^3.3.11 range already admits the fix, so this is a lockfile-only
bump with no override — same as the previous 3.3.16 -> 3.3.17 bump.
3.3.18 was published 2026-08-07 and is now past the workspace
minimumReleaseAge, so no exclude is needed either.

pnpm install --frozen-lockfile and pnpm audit --audit-level=high verified
locally (0 high; 4 low / 5 moderate remain, below the threshold).

- `/manage/period/$periodId` now has two faces. Edit is opt-in via `?mode=edit`; View is the absence of that param, and `validateSearch` normalizes any other value to View. A View/Edit toggle sits in the header, hidden when there is no wallet or the period is frozen.

- Every write affordance now gates on one flag: `showEditControls`, defined as connected SDK + `mode === 'edit'` + `editable`. `editable` now means the period is not frozen, based on readiness and votes. This replaces the previous status-based definition.

- Dropped the `status === 'upcoming'` condition. The contract's `editPeriod` only asserts operator, `!ready`, and `end > start`, so a draft whose voting window is active or has passed is still editable on chain.

- A ready period with no votes cast is still editable because it can be reverted to draft. It keeps edit controls live in Edit mode and shows a warning that changes will fail until it is reverted. The contract, not the UI, rejects those writes.

- Added `src/utils/periodEditing.ts` with shared `periodHasVotes` and `periodFrozen`, used by the list and detail page. A ready period with votes cast is frozen, so it gets no Edit affordance and no View/Edit toggle.

- Manage periods list: the title cell links to View, and the actions column holds a single button per row: Edit, or View for a frozen period.

- Misc: the Upcoming status chip no longer uses `bg-accent`; it now uses a custom soft pink so it is visually distinct from Ended. This intentionally uses a Tailwind color outside the design tokens because it only appears in the operator-only Manage UI.

The pink Upcoming chip was not operator-only: `PeriodStatusBadge` also renders on the period detail, results and account pages. Back on design tokens, reusing the tones `PeriodStatusTag` already had, so a status looks the same wherever it appears. The two badges are merged, with union props so neither list rows nor detail pages recompute a status they already hold.

feat: enforce Abstain as the last topic option

- Mirror the GT_OA rule from `ensureValidOptions` in the manage panel, so an operator cannot build an option list the contract will reject.

- There's a fixed row with "Abstain" option, locked and without move/remove controls. Both editors hold only the custom options and append Abstain at call time.

- Frontend is even stricter than the contract: enforces `MIN_CUSTOM_OPTIONS=2` (at least two non-abstain options) and rejects an operator-typed Abstain in any casing.

- Create a new utils file for topic options to centralize validation for add/edit topic options. Also adds the missing duplicate-option check to AddTopic.

chore: /docs wording

There are TWO arrows out of the committed artifact, not one, and neither was
checked:

    contracts/out/TrelyanInscription.*
        |  algod compile                |  algokit generate client
        v                               v
    bytecode ==? chain              contracts/trelyan_client.py

The client branch matters more than it looks. contracts/trelyan_client.py is an
89 KB generated file stamped "DO NOT MODIFY IT BY HAND", and the LocalNet suite
deploys the committed TEAL and drives it THROUGH that client. CI only ever
consumes it; nothing regenerated it and compared. A contract whose ABI moved
without the client being regenerated would be exercised by a suite talking to
the old interface -- and the suite would pass.

CHECKED WITHOUT RUNNING THE GENERATOR, DELIBERATELY

`algokit generate client` needs algokitgen-py, which would pin this check to a
generator version whose formatting churn is not a finding. It is also, on the
machine this was written on, blocked outright by a Windows Application Control
policy (os error 4551) -- the same policy that currently blocks cargo-deny.

No generator is needed: the client EMBEDS the full spec it was generated from,
in _APP_SPEC_JSON. Comparing that to the committed arc56.json needs nothing but
the two committed files, runs anywhere, and is stable across generator versions.

The comparison is on PARSED JSON rather than bytes, because the client embeds
the spec minified while arc56.json is pretty-printed -- a byte comparison would
fail always and therefore mean nothing.

Failure reporting distinguishes an ABI-method change (names differ; the suite is
testing a different interface) from a signature/struct/metadata change (names
agree), because those read very differently to a reviewer.

VERIFIED

  - clean tree: all five artifacts plus the client in step, exit 0
  - rename a method inside the client's embedded spec: CLIENT DRIFT, exit 1,
    naming both method lists
  - a missing _APP_SPEC_JSON block is reported as "repair the check", not
    silently passed -- if the generator's output shape changes, this check stops
    reading what it thinks it reads, and that is a finding about the check