What belongs in a Plane Page, and what belongs in a Work Item?

When crafting a feature description, it's crucial to keep the Work Item focused on the specific implementation task at hand. As the description grows to include background information, future plans, acceptance criteria, and test results, it becomes increasingly difficult for implementers to grasp the scope of the current change.

Instead, it's more effective to determine how long the information remains relevant. If assumptions shared by multiple changes are kept in a Page, while the conditions for completing the current change remain in its Work Item, it allows for a clearer separation between the two.

For instance, in the case of SquadNote, a personal project, the Plane Project underwent inspection and comparison on September 11, 2026. Initially, the Plane's Pages listing contained no entries. The proposed structure below outlines a proposal based on existing tickets. Within a lengthy parent ticket, SQN-29 serves as the parent ticket for introducing a staged transition from trial participation to full membership.

This ticket includes trial permissions, manual promotion, termination, communication, application flow, progress tracking, and follow-up after expiration.

Meanwhile, SQN-30 focuses on the concrete implementation task of introducing trial participant permissions and manual promotion and termination. Its scope covers API authorization, compatibility with existing invitation URLs, and promotion and termination behavior. However, communication features and automatic expiration processing fall outside the scope of this Work Item.

By clearly delineating the scope, implementers can easily determine whether the current task is complete without getting overwhelmed by unrelated details.

Information is deemed relevant when it is needed, and its location should reflect this. For example, when a trial ends, the relationship with an organization is severed, rather than the entire account being deleted. This rule should be shared across all implementation stages. Shared rules and their rationale should reside in a Page, while the Work Item should clearly define the conditions for completion.

In the example of SquadNote, permissions are agreed upon across multiple platforms, and acceptance criteria must be met for the task to be considered finished.

A separate test document can be created to record findings for a specific revision, allowing for a distinction between checked and unchecked items. This test record should be linked to the relevant Work Item to provide context and maintain a clear audit trail. Development invitation details, however, should not be included in a public specification, as they do not contribute to the overall definition of the feature.

To apply this approach, start with a parent ticket that contains multiple shared assumptions. Extract these assumptions into a Page, and ensure that the Work Items within the ticket still contain their respective scope and acceptance criteria. This method simplifies the understanding of a feature's requirements, implementation tasks, and completion conditions, ultimately leading to more efficient development processes.