Trello board archiving: define the API v1 closed-state contract

Assume the current Trello API remains on v1 and that the documented board archive or close state is represented by a closed board property. The goal is to define a compatibility contract for clients that move between the web interface and API-managed board state.

The key uncertainty is whether “archive” in the UI and closed in API responses guarantee the same state transition across board reads, member-board listings, and later reopening. A contract should also state whether archiving changes board membership, visibility in filters, or access to existing lists and cards. Those effects matter to automation that treats an archived board as temporarily inactive rather than deleted.

This is a board-state question, not a request to roll back Trello’s internal schema migrations; standard accounts do not control those migrations. Current API v1 documentation and release notes should be checked before relying on the exact update operation or response fields.

Should API board updates and UI archiving share one documented state transition? Which observable fields and membership relationships must remain unchanged when a board is reopened?