DEV Community: hiro@

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

hiro@ — Sat, 26 Sep 2026 02:11:18 +0000

The more thoroughly you describe a feature, the longer its Work Item becomes. Background, future plans, acceptance criteria, and test results accumulate in one description. Eventually, the implementer has to search for the scope of the current change.

A useful boundary is how long the information remains relevant. Put assumptions shared by multiple changes in a Page, and keep the conditions for completing the current change in its Work Item.

The example is SquadNote, a personal project. On September 11, 2026, its Plane Project was inspected through read-only access and compared with documents in Git. The Project's Pages listing contained 0 entries at that time. The Page structure below is a proposal based on existing tickets.

Find the different jobs inside a long parent ticket

SQN-29 is the parent ticket for introducing a staged transition from trial participation to full membership. Its description covers trial permissions, manual promotion and termination, communication, an application flow, progress tracking, and follow-up after expiration.

SQN-30, titled “[Step 1] Implement trial participant permissions and manual promotion and termination” in translation, is a concrete implementation task. Its scope includes API authorization, compatibility with existing invitation URLs, and promotion and termination behavior. Communication features and automatic expiration processing are outside that scope.

Both descriptions contain requirements, but those requirements serve different purposes.

Information	When it is needed	Proposed location
Ending a trial removes the relationship with an organization, not the entire account	Across later implementation stages	Shared rules in a Page
The initial stage uses manual promotion and termination	To define this change	Work Item scope
Permissions agree across Web, iOS, and Android	To determine whether this change is complete	Work Item acceptance criteria
A later stage will handle follow-up after expiration	To plan subsequent work	Parent and later Work Items
What was checked, against which revision	During review or retesting	A reference to a test document in Git

The material worth extracting into a Page is the context likely to be copied into several implementation tasks. Moving the current task's scope there too would make the ticket insufficient for judging completion.

Keep shared rules and their rationale in the Page

Plane's Pages documentation describes Pages as a place for project requirements and other documents. Work Item mentions and creating Work Items from selected text carried a Business label when checked. The proposed information structure does not depend on having those editing conveniences.

For this feature, an initial Page could be as small as this:

Trial participation

Purpose
- Represent participation before a person decides to become a full member

Shared rules
- Ending a trial ends the relationship with the organization
- It does not delete the entire account
- Enforce permissions in the API as well as the interface

Scope by stage
- Initial: manual promotion and termination
- Later: communication, applications, progress, and follow-up after expiration

Related work
- Parent ticket
- Work Items for each stage

Change history
- Assumptions that changed and the reasons for changing them

This is a proposed outline extracted from the tickets, not an excerpt from an existing Page. It does not introduce another implementation-status checklist.

When a shared rule changes, review the affected open Work Items as well as editing the Page. For example, changing which history must survive trial termination also changes the termination API's acceptance criteria. Links help locate the affected work; they do not keep the linked descriptions consistent automatically.

Leave testable completion conditions in the Work Item

A reference to the shared rule “enforce permissions in the API” is not enough to define this implementation. The ticket needs conditions that someone can check. The following examples make the existing scope more explicit:

A trial participant cannot retrieve data by calling an API outside their permissions.
Promoting a participant gives them the required permissions in that organization.
Ending the trial does not delete the entire account or relationships with other organizations.
The existing invitation flow still works.

These conditions let a reviewer separately assess alignment with the Page and completion of the current ticket.

Adding future communication features to the same checklist would prevent the manual-promotion task from closing even after its implementation is finished. Link subsequent work without adding it to the current definition of done.

A test record describes a different state from a specification

The related repository contains docs/testing/sqn-30-trial-participant-checklist.md. It was inspected at circle-hub commit 0cda1e8; the document's addition appears in commit 12cbb78. The review used this fixed repository revision.

The document has completed Web checks and unfinished manual mobile checks. It also limits the work to verification in the development environment, excluding production deployment.

That supports the statement that a test document exists and distinguishes checked from unchecked items. A feature plan in the parent ticket, or a partially completed checklist, does not establish completion on every device. The application checks were not rerun for this article either.

The Page describes the intended rules, the Work Item describes the change, and the test document records findings for a particular revision. Linking the Work Item to the test document's commit can preserve that time reference. Development invitation details do not belong in a public specification example.

Try the split with one long ticket

Start by trying the split with one parent ticket. Choose one with repeated shared assumptions, extract those into a Page, and check that its child Work Items still contain their scope and acceptance criteria.

Then ask whether someone can start work from a child ticket and whether a changed shared rule can be traced to the affected tasks. No Pages were created during this investigation, so there is no measured reduction in search time to report.

A small fix may fit comfortably in one description. The reason to create a Page is that its assumptions need to remain useful across later work, rather than that the current ticket has reached a particular length.

Zero updated rows do not fail a D1 batch: testing the rollback boundary

hiro@ — Fri, 25 Sep 2026 02:05:50 +0000

Suppose a D1 batch() reduces stock and then saves an order. If the UPDATE affects zero rows when stock is insufficient, will the order also remain unsaved?

In a local D1 binding experiment, the INSERT succeeded even when the UPDATE affected zero rows. Throwing a JavaScript exception after batch() returned did not remove the saved order.

SQL failure and an unfulfilled business operation need separate treatment. batch() provides atomicity when SQL fails. It does not automatically turn the application's conclusion that stock was unavailable into a SQL error.

Start with a SQL statement that fails

The official D1Database documentation describes sequential execution of the statement array, aborting or rolling back the sequence if a statement fails. The result array corresponds to the input statement order.

This small schema makes it possible to examine what qualifies as failure. It is an experiment about the guarantee, not a change deployed to a real inventory service.

CREATE TABLE stock (
  id INTEGER PRIMARY KEY,
  remaining INTEGER NOT NULL CHECK (remaining >= 0)
);
CREATE TABLE orders (
  id TEXT PRIMARY KEY,
  quantity INTEGER NOT NULL
);

Before each case, the tables are reset and stock receives a row with id = 1 and remaining = 1.

First, an UPDATE reduces the stock by one, followed by an INSERT using an order ID that was already registered before the batch:

await db.batch([
  db.prepare("UPDATE stock SET remaining = remaining - 1 WHERE id = 1"),
  db.prepare("INSERT INTO orders VALUES (?, ?)").bind("duplicate", 1),
]);

The call throws a primary-key uniqueness error. Reading the database after catching it shows that the remaining stock is back to one and only the previously registered order exists. The earlier UPDATE was rolled back too.

In a separate successful batch containing UPDATE, INSERT, and SELECT, the final SELECT returned the updated remaining stock of zero. This also confirmed that later statements can observe earlier changes in the sequence.

No matching row is not a SQL error

Next, try to order two units when only one remains:

const result = await db.batch([
  db.prepare(
    "UPDATE stock SET remaining = remaining - ? WHERE id = 1 AND remaining >= ?",
  ).bind(2, 2),
  db.prepare("INSERT INTO orders (id, quantity) VALUES (?, ?)")
    .bind("order-b", 2),
]);

console.log(result.map(item => item.meta.changes));

The output was [0, 1]. The UPDATE changes nothing because the remaining stock fails its predicate. The statement itself does not fail, however. The INSERT succeeds, leaving stock at one and saving an order for two units.

There is no JavaScript branch inside this batch that examines the UPDATE result and cancels the INSERT. Both statements were placed in an array and submitted in advance.

A conditional UPDATE can help determine whether an individual update occurred. When another table's update must depend on that outcome, you also need to design how zero affected rows influence the later operation.

Throwing after the batch is too late

After receiving the result, the experiment ran this check:

if (result[0].meta.changes !== 1) {
  throw new Error("No stock was reserved");
}

The exception occurs. Reading the database after catching it still finds order-b. By the time await db.batch(...) returns successfully, its SQL execution has completed. A later JavaScript exception does not undo that batch.

Case	SQL result	Final remaining stock	Orders
Successful update and registration of one unit	Success	0	One new order
Duplicate ID in later INSERT	Error	1	Only the preexisting order
Two-unit request excluded by WHERE	Success, changes are zero and one	1	One new two-unit order
Negative stock rejected by CHECK	Error	1	Zero orders

The final row comes from the following variation.

Can a constraint express the invalid outcome?

The fixture includes a CHECK constraint that disallows negative stock. Removing the stock predicate from the UPDATE makes a two-unit decrement violate that constraint:

await db.batch([
  db.prepare("UPDATE stock SET remaining = remaining - ? WHERE id = 1")
    .bind(2),
  db.prepare("INSERT INTO orders (id, quantity) VALUES (?, ?)")
    .bind("order-c", 2),
]);

This case fails with a CHECK error, leaving one unit and zero orders. For this input, expressing the invalid business outcome as a SQL constraint violation makes the entire batch fail.

The snippet is not a complete inventory system. If the stock row with id = 1 does not exist, the UPDATE still affects zero rows. Validating quantities, relating products to orders, repeated order submissions, and multiple products are also outside this experiment. One CHECK constraint does not detect every unsuccessful business operation.

When choosing an implementation, list the conditions that should count as failure. For each one, determine whether SQL throws or completes successfully with zero changes. For the latter, examine whether conditions or constraints within SQL can connect it to the later update, or whether the unit of work needs to change.

Reproduction environment and limits

The experiment ran on September 11, 2026, with Node.js v24.15.0, Wrangler 4.81.1, and Miniflare 4.20260409.0. Wrangler's getPlatformProxy supplied the local D1 binding with persist: false and remoteBindings: false. The configuration requested compatibility date 2026-09-11.

The experiment script includes table creation, all four cases, and assertions on the resulting rows. Its first argument is the path to an installed Wrangler package's package.json:

node experiments/article-stock-2026-09/d1-batch.mjs \
  ../circle-hub-multi-device-push/apps/web/node_modules/wrangler/package.json

The local binding is an emulation of production. This is not a load or failure test against production D1. It also does not test lost network responses, external payment or notification systems, or multiple concurrent requests.

A later throw did not undo the batch that had already returned successfully. Grouping statements is only part of the work: identify which SQL statement expresses each invalid outcome as an error.

Split Plane Workspaces or Projects based on who may administer the data

hiro@ — Thu, 24 Sep 2026 01:49:09 +0000

Putting personal projects and company work in one Plane workspace can be appealing. It avoids switching screens and keeps today's tasks together.

The mistake is assuming that a Private Project also creates a space independent of workspace administrators. Before splitting projects, decide whether the administrators of the same Workspace may see the information.

This is a design proposal based on official documentation checked on September 11, 2026. It is not an investigation of a company Workspace or a record of migrating an existing Plane setup. Actual permissions require checking the edition, role configuration, and installed version.

Private Projects still have an administrator exception

The official Project documentation limits Private Projects to explicitly invited members while also allowing Workspace Admins to access them.

The Member roles reference adds that the former workspace-level Admin role was renamed Owner. Owners have access throughout the Workspace, and Admins can access project content without being added as project members.

The official pages contain both older and newer role names. Rather than deciding from the word “Admin” in a screen, check whether the role administers the Workspace or only an individual Project.

Personal tasks that should not be shared with company administrators do not belong in a Private Project inside the company Workspace. If the administrator is shared and only the usual participants or workflow need to differ, Projects remain a possible boundary.

Write down whether the boundary concerns administration or work

The Workspace overview describes a Workspace as the unit containing Projects, with membership and integration settings managed at that level.

The following are example design choices, not a list of settings already applied to an environment:

Reason for separation	Unit to consider	Deciding factor
Personal and company work have different administrators	Workspace	Keep membership and administrative authority separate
One person administers both a web app and a game	Project	Shared administrator, different work
A project in one organization needs limited participation	Private Project	Workspace administrator access is acceptable
An improvement effort is open to the organization	Public Project	Workspace members can discover and join it

Creating another Workspace merely because the ticket count grew mixes organizational convenience with an administrative boundary. Decide who administers the data first, then split Projects within that scope.

Personal work with multiple collaborators does not automatically belong in a single Workspace either. Name the people who will keep administering it, decide invitations, and receive access to the work. Then determine whether they fit under the same administration.

Public Projects and Internet publication are separate

“Public” can also cause confusion. Public in a Project's visibility settings is described as allowing Workspace members to discover and join the Project themselves. Guests need an explicit invitation.

There is a documentation distinction here: the Project overview describes member access broadly, while the roles page says that access to content requires joining the Project. These descriptions do not establish identical behavior for every screen. For design purposes, treat it as a scope that ordinary members can join themselves, and verify it with the actual role.

A separate Publish Project feature creates a public page that can be viewed without signing up.

These are therefore separate settings:

Which people in the Workspace can join or access the Project.
Whether viewers outside the Workspace receive a public page.

A request for an external roadmap does not mean every detail in the working Project needs to become public. Include a procedure for choosing what to expose. No publishing or permission changes were performed for this article.

Your administrator view is not a complete permission test

Being able to open a Project as its administrator does not establish what an ordinary member sees.

For verification in the target environment, use test data without confidential content and distinguish an ordinary member who has not joined the Project from a Workspace administrator. For both Private and Public Projects, record whether each role can discover it, open its URL directly, and join without an invitation.

Check published pages in a browser that is not logged into the Workspace. Testing participation permissions inside a Project and testing a published page's visibility are separate tasks. Those checks with different roles were not performed in this investigation.

Separate Workspaces also do not, by themselves, establish separate account authentication or isolation of a self-hosted infrastructure. The boundary discussed here is Plane's administrative unit. Infrastructure isolation and company authentication policy require their own checks.

When unsure where to split, first answer: may the person administering this Workspace open this Project? If yes, choose the Project's visibility and participants within it. If no, reconsider which Workspace should contain it. That order keeps organizational convenience from obscuring the administrative boundary.

When retrying scheduled publication avoids duplicates, and when a lost response breaks it

hiro@ — Wed, 23 Sep 2026 01:59:56 +0000

Whether it is safe to rerun a failed publishing command depends on where it failed. Retrying before an external service creates the article can attempt a new publication. Retrying after creation, when only the response was lost, can create another article.

This repository stores Qiita's id and dev.to's devto_id in the article files, then uses those IDs for updates on subsequent runs. That supports recovery when the IDs have been saved. It does not provide complete duplicate prevention.

The publisher at commit 8a1bfa8 was executed with external APIs and file operations mocked to establish that boundary. This article describes the implementation and a proposed recovery procedure for its remaining gap. It does not report an actual duplicate-publication incident.

A saved ID turns the next attempt into an update

scripts/publish-scheduled.mjs reads the selected day's entry and handles Japanese publication before English. For Qiita, an existing id selects PATCH; otherwise it uses POST. For dev.to, devto_id selects PUT; otherwise it uses POST.

POST to Qiita
  ↓ obtain id from the response
Save id in the Japanese file
  ↓
POST to dev.to
  ↓ obtain id from the response
Save devto_id in the English file

When both files have the required IDs and published flags, the script exits successfully without calling an API.

When only the Japanese side is complete, the behavior is slightly different. The current implementation runs the Qiita operation again, but uses PATCH because it has the ID. It then POSTs to dev.to, which still has no ID. Describing this as "retrying only the English post" would not match the code.

Scheduled attempts and retries inside one job serve different purposes

The workflow schedules a start corresponding to 08:55 JST and another at 09:10. The earlier start waits until 09:00. Within a job, it tries the publisher up to 3 times, waiting 30 seconds and then 60 seconds after failures.

A retry within that job can reuse IDs already saved in its files. A separate run needs the changed frontmatter to have been committed to Git. The workflow has a metadata persistence step using if: always(), but that does not guarantee success if the step or its push fails.

A concurrency group also limits simultaneous publishing by workflows in that group. It does not make the external service's POST idempotent.

GitHub documents delays under high load. Adding another scheduled attempt does not guarantee publication at the desired time.

Run the actual script without sending externally

The experiment ran on September 11, 2026, with Node.js v24.15.0. The reproduction script reads the publisher from Git, removes its two imports, and runs it in a VM. It supplies test replacements for file access, fetch, and environment variables.

node experiments/article-stock-2026-09/publishing-recovery.mjs

No real API requests are sent. The fake server increments its article count whenever it accepts a POST and can lose the response afterward. Fake files persist between attempts, exposing the difference between failing before and after an ID is saved.

First attempt	Calls on retry	Final fake-server count: Qiita / dev.to
Both posts accepted and IDs saved	None	1 / 1
Qiita ID saved, then dev.to returns 422	Qiita PATCH, dev.to POST	1 / 1
Qiita accepts, then response is lost	Qiita POST, dev.to POST	2 / 1
dev.to accepts, then response is lost	Qiita PATCH, dev.to POST	1 / 2
Qiita accepts, then local persistence fails	Qiita POST, dev.to POST	2 / 1

A separate dry-run check produced zero API calls and zero fake-server articles. Assertions verified all 6 cases.

This does not measure how often a real service loses a response. It checks which information the script has when choosing its next request. The fake server covers the Qiita and dev.to paths, not Zenn's Git integration or waiting inside actual GitHub jobs.

Recover the ID before deciding to retry

The results support this proposed operational sequence:

Fix the target date and use dry-run to check the Japanese and English paths.
Inspect the failed run's log and the IDs saved in the files.
If a timeout or similar failure leaves acceptance uncertain, look for an existing post in the platform's article list or editor.
Once the matching post is identified, recover its actual ID and status before rerunning.
If creation cannot be established, stop automatic new POST attempts and continue investigating.

This is a proposed procedure for operating the existing script, not an implemented automatic reconciliation feature. Compare the body, target date, and canonical as well as the title. Never invent an ID.

Dry-run is available through this command, replacing the date with the one under investigation:

node scripts/publish-scheduled.mjs --date=2026-08-04 --dry-run

The reported publication state comes from local frontmatter. A successful dry-run does not establish that there are no externally created posts missing from local records.

Start further automation at the persistence boundary

One possible improvement is to record states such as not sent, acceptance unresolved, and ID saved. An unresolved acceptance could prevent another automatic creation request. A reconciliation procedure would still be required.

The current implementation does not have this mechanism. More local state does not remove the interval in which the external service has created an article but its ID has been lost. Whether the service supports idempotent creation or a reliable way to locate the result needs separate investigation.

In the tested code, failures after the ID is saved can be retried as updates. Failures after external acceptance but before ID persistence can return to a new POST. Recovery should distinguish those cases instead of treating both as a single "failed" state.

Reusing a game jam repository starts with event boundaries and explicit export targets

hiro@ — Tue, 22 Sep 2026 02:02:09 +0000

After a game jam, source code is only part of what is worth keeping. The procedure for building the submission ZIP, the export preset, and the test command are useful material for the next event too.

Keeping an old game and building a reusable library are different amounts of work. An inspection of game-jam-lab found an event-based structure containing documents and tools, but not a completed SDK shared by every event.

This article examines a design that leaves room for more events while making the target of each test and export explicit. The inspected version is commit f074703, checked on September 11, 2026. Ongoing uncommitted work is not counted as completed functionality.

Keep the submission's parts together

The relevant parts of the committed structure look like this:

events/
  2026-ai-browser-game-jam-4/
    godot/
      project.godot
      shared/
      tests/
    docs/
    tools/
    submission/

This commit tracks one event. The structure is being evaluated as a place to add the next event, not as evidence of completed operations across multiple events.

Keeping the game, design notes, tools, and submission material under the event makes the intended submission traceable from a path. Compared with mixing several games' project.godot files and ZIP-building logic at the repository root, it gives the next event a clear home while preserving the previous one.

Copying a folder does not necessarily prepare the next submission, though. The event name, game name, export preset, and publication destination still need checking. Separate storage does not automatically switch those settings.

Resolve the target from the script's own location

The itch.io export script derives the event root from its own location, rather than the caller's current working directory:

script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
event_root="$(cd "$script_dir/.." && pwd)"
godot_root="$event_root/godot"
output_dir="$event_root/build/itch/volt-nomad"
archive_path="$event_root/build/itch/volt-nomad-web.zip"

It resolves godot_root before passing it to --path. Output also lives under that event's build/ directory. Running the script from the repository root or inside the event therefore targets the same project.

This does not make the script ready for the next event without changes. The output name volt-nomad and preset Itch Volt Nomad remain specific to this game. They need attention when copying the script. Before generalizing the script, make its game-specific values easy to identify.

Test path resolution and ZIP layout separately

To examine this behavior, the actual script from the fixed commit was extracted into a temporary directory. The event directory was renamed for the fixture, and a small stub replaced the Godot executable.

The stub records its arguments and creates fixture files named index.html, index.js, index.pck, and index.wasm. It does not export a game through Godot. The original shell code still creates the ZIP and checks its required files.

Working directory	Target passed to `--path`	Four files at ZIP root
Fixture repository root	That event's `godot/`	All present
That event's `godot/`	That event's `godot/`	All present

The script also passed bash -n. The verification code ran with Node.js v24.15.0:

node experiments/article-stock-2026-09/game-jam-layout.mjs ../game-jam-lab

This verifies path construction and ZIP layout. Game startup, a successful Web export, and running on itch.io require separate checks. The inspected CI specifies Godot 4.6.2, but this experiment did not execute Godot.

Read the scope of `shared/`

The event's godot/shared/ directory contains files for controller input, palettes, audio settings, and synthesis. They live inside the event. They are not a repository-level common tools/ directory or a library extracted for use across events.

That scope matters when reusing code in the next game. Code shared within an event can reasonably know the names and settings of that event's games. Moving it elsewhere requires checking dependencies such as input action names and save locations.

A possible next step is to copy the code into the next event and inspect the resulting differences before moving it into a common library. If the game name is the only recurring change, an argument or setting might be enough. If progression logic and assets must also be rewritten, keeping that part inside the event may remain easier to understand.

The evidence for extraction is what two events can use unchanged, not the directory name shared. That comparison has not yet been performed here, so there is no measured time saving to report.

Adding an event does not select it for CI

The Pages workflow hardcodes events/2026-ai-browser-game-jam-4/godot as the --path for smoke tests and Web export. It does not discover and run every directory under events/.

Adding the next event's folder therefore does not automatically test the next game. The workflow needs an explicit choice of which projects to test, which to publish, and which merely to preserve.

A future design could separate a list of verification targets from a single publication target. Checking older events for syntax or startup problems and deciding whether a new game should replace the published build are separate decisions. This design is not implemented in the inspected commit.

To leave the repository usable for another event, preserve the event's parts and inspect what its scripts and CI point to. In this structure, the export script's relative placement can carry forward. The game-specific output names and the fixed CI target are choices to revisit for the next event.

Reviewing AI-generated code by breaking one invariant and reading the failing test

hiro@ — Mon, 21 Sep 2026 01:54:27 +0000

An AI assistant returns a diff and tests, and every test passes. The awkward moment comes when you still cannot explain, in your own words, what those tests protect.

One review technique is to choose an invariant, deliberately break it, and check whether a test fails. The failing expectation points to the condition it protects in the implementation.

For this article, SquadNote's real notification router and existing tests were extracted into a temporary copy. Removing one deletion condition changed the result from eight passing tests to seven passing tests and one failure. The check ran on September 11, 2026, using Node.js v24.15.0 and Vitest 4.1.4.

This experiment does not establish who wrote the code. It presents a review procedure that also applies to code received from an AI assistant. It describes the procedure tested here, without claiming benefits from continued use.

Turn “logout works” into a condition about stored data

The example deletes a device's push token. Consider a device that switches from account A to account B, followed by a delayed deregistration request from A.

“Logout works” leaves too much room for interpretation. The invariant here is:

A request from former owner A must not delete a device token that has moved to B.

This identifies the actor, the target, and the data that must survive. It translates into a test more readily than “handle authorization correctly.”

The relevant deletion predicate is:

and(
  eq(pushTokens.userId, ctx.session.user.id),
  eq(pushTokens.token, input.token),
)

The token must match, and its current owner must match the session user. Registration and ownership transfer form a larger topic; this review stays focused on the deletion predicate.

Write the counterexample before changing the code

Start with the sequence of operations:

A registers ios-1 and android-1.
B registers android-1, transferring that token's ownership to B.
A requests deregistration of android-1.
B's android-1 and A's ios-1 must remain.

The existing test already follows this sequence. It reads the database rows afterward instead of merely checking whether an API was called. Its final expectation is:

expect(await rows()).toEqual([
  { user_id: "user-b", token: "android-1", platform: "android" },
  { user_id: "user-a", token: "ios-1", platform: "ios" },
]);

It also matters where rows() reads from. These tests use the actual router and a libSQL test database, with external HTTP mocked. If unregisterPushToken itself were replaced by a mock that always succeeded, the test would not exercise this predicate.

Remove only the user condition

The experiment extracted commit 0cda1e8 into a temporary directory and ran the original tests. It then changed the predicate, only in that copy, to:

eq(pushTokens.token, input.token)

This is an injected fault for examining the tests. It is not a proposed production change. Deleting by token alone should allow A's stale request to remove B's registration.

Code	Passed	Failed	Observation
Original deletion predicate	8	0	Existing expectations hold
User condition removed	7	1	Deregistration after account transfer is detected

The failing test was the one asserting that switching accounts transfers only that device and that the previous owner cannot delete it. Its expectation about the stored rows no longer matched.

A test that was already failing would not establish this difference. A syntax error that prevented the suite from starting would not establish that the intended invariant was detected either. Here, the failure occurred at the test's data expectation.

The experiment script extracts the fixed commit, runs the baseline, removes the condition, and runs the tests again without modifying the original repository. With the source project's dependencies already installed, run it from the article repository:

node experiments/article-stock-2026-09/mutation-check.mjs ../circle-hub-multi-device-push

What to inspect if the test still passes

This counterexample was detected. If a different mutation leaves a suite green, first check whether the counterexample reaches the intended code before adding more tests.

For example, a mock that always supplies user A cannot establish a transfer to B. An assertion that checks only a successful response, without reading the rows afterward, can miss excessive deletion. The test might also exercise a different router from the one you changed.

Read the input setup, the invoked function, the mocks at external boundaries, and the final expectations in that order. Once you know which components actually run, add the missing counterexample.

This procedure establishes that a chosen test detects a chosen fault. It does not prove the absence of every authorization bug, every problematic concurrent ordering, or failures in delivery to a real device. This experiment did not use external delivery or physical devices.

When asking an AI assistant for an explanation, “Which data would disappear if this condition were removed, and which expectation would fail?” produces an answer you can compare with execution. Record the invariant, the counterexample, and the expectation that actually failed. That record helps the next reviewer decide whether the same condition can be removed during a cleanup.

Comparing Promise.all, allSettled, any, and race when failure arrives first

hiro@ — Sun, 20 Sep 2026 01:53:35 +0000

When work can partially fail, decide which event should settle the aggregate Promise. Replacing Promise.all with allSettled does not change how many operations start or how they can be cancelled.

The comparison passes A, B, and C in that order, then rejects B, fulfills C, and finally fulfills A.

Method	Immediately after B fails	Result observed after all inputs settle
`all`	Rejected	B's error
`allSettled`	Pending	An array: A fulfilled, B rejected, C fulfilled
`any`	Pending	C's value, the first fulfillment
`race`	Rejected	B's error, the first settlement

The test environment was Node.js v24.15.0 on September 11, 2026. This checks a controlled settlement order, not wall-clock speed.

Specify completion order without timers

Promise.withResolvers() returns a Promise together with externally callable resolve and reject functions. The core of the comparison is:

const a = Promise.withResolvers();
const b = Promise.withResolvers();
const c = Promise.withResolvers();

const result = Promise.allSettled([a.promise, b.promise, c.promise]);
b.reject(new Error("B failed"));
c.resolve("C result");
a.resolve("A result");

console.log(await result);

There is no real network request here. The result follows the input order A, B, C, rather than the completion order B, C, A. A batch can use that ordering to associate each result with its original input.

The complete reproduction runs the four methods separately and asserts both their state after B's failure and their final result.

node experiments/article-stock-2026-09/promise-combinators.mjs

The settlement rules were also checked against the ECMAScript Promise specification. This comparison supplies an array of ordinary Promises; exceptions thrown by the input iterator itself are a separate case.

The remaining inputs still exist after rejection

After all and race rejected with B's error, the experiment could still fulfill C and A. Rejection of the aggregate did not cancel the input Promises.

In a notification batch, some requests might already have been sent. Resending every item simply because execution reached all's catch handler could duplicate successful sends. Aggregating results and deciding how to stop or retry individual operations need separate policies.

The same applies to race. If a timeout Promise settles first, the competing network operation is not automatically stopped. Cancellation requires a mechanism supported by the operation itself. Implementing cancellable fetches or timers is outside this experiment.

A synchronous throw can happen before allSettled receives anything

This version throws while constructing the array:

const jobs = [
  () => 1,
  () => { throw new Error("sync failure"); },
  () => 3,
];

await Promise.allSettled(jobs.map(job => job()));

Because map never finishes, execution never reaches the call to allSettled. To collect failures from every job as results, move each invocation into a Promise:

const results = await Promise.allSettled(
  jobs.map(job => Promise.resolve().then(job)),
);

The resulting statuses were fulfilled, rejected, and fulfilled. This is not special handling of synchronous exceptions by allSettled: the exception inside then becomes rejection of that input Promise.

It still does not impose a concurrency limit. It only moves function execution into Promises. If a large set of jobs must not start together, choose a worker count or queue separately.

Include empty input in the caller's contract

For an empty array, all and allSettled fulfill with an empty array. any rejects with an AggregateError whose errors array is empty, and race stays pending. The same script checks these cases.

For example, passing an empty list of candidate servers straight to race will not produce a result. Decide in advance whether zero inputs mean success or an invalid request.

In this comparison, allSettled collects every outcome; all requires every input to succeed; any needs one success; and race observes the first settlement regardless of success or failure. None of those choices alone determines persistence or cancellation behavior.

Choose Next.js Server Actions or Route Handlers by the contract with the caller

hiro@ — Sat, 19 Sep 2026 01:50:47 +0000

When writing a server-side mutation in Next.js, the same business logic can appear to fit inside either a Server Action or a Route Handler. Memorizing “Actions for forms, Routes for APIs” becomes less helpful when a mobile app or a cron job needs to invoke it too.

The choice starts with the contract you want to give the caller. An Action is a candidate when the operation belongs to a Next.js screen, including its navigation flow. A Route Handler fits when you want to explain a URL, HTTP method, authentication header, and JSON result to another caller.

SquadNote's form and cron endpoint provide concrete examples. The inspected source is commit 0cda1e8, with Next.js 15.5.15 and React 19.2.5 installed locally. The official documentation consulted on September 11, 2026, displayed version 16.3.4. The current documentation and the version actually tested are recorded separately.

The form passes the authentication operation and return destination together

The account-linking screen contains code equivalent to this shortened excerpt:

<form
  action={async () => {
    "use server";
    await signIn(p.id, { redirectTo: "/settings" });
  }}
>
  <button type="submit">Connect</button>
</form>

Styling and other button details are omitted. Here, p is an authentication provider enumerated by the screen. The form starts that provider's authentication flow and specifies a return destination appropriate for the screen.

This Action is the entry point for a screen operation. It does not need to define a JSON format for a separate client.

The official Mutating Data guide describes a Server Function used in a form or mutation context as a Server Action. Its transport uses POST, and it can also receive direct POST requests outside the application's UI. A button being visible only on one screen does not make that screen's permission check sufficient.

The excerpt starts authentication; it is not an authorization template for arbitrary mutations. Replacing it with post deletion, for example, requires checking the acting user and their relationship to the post.

The cron endpoint has HTTP results to return

The morning notification route exports POST(request: Request). Its sequence is:

POST /api/cron/morning-reminder
  Read the configured secret
  Missing configuration → 500
  Authorization header mismatch → 401
  Query today's schedules
  Send push notifications if there are recipients
  Return a JSON result

The cron caller needs to know which method to use, which header to attach, and which result to expect. Passing a function to a form is not its interface. A Route Handler, built around the Web Request and Response APIs, fits that need.

For the same reason, defining an HTTP contract helps when an endpoint will serve mobile apps or external services. Choosing a Route Handler does not, by itself, specify authentication or the behavior of repeated requests.

Verify that rejected requests stop before database access

The route from the fixed commit was extracted into a temporary directory, and its exported POST function was invoked directly. Database access and push delivery were mocked to check that execution stopped before reaching them when authentication conditions were unmet.

Input	Status	Database accessor	Push delivery
No configured secret	500	Not called	Not called
Secret configured, header absent	401	Not called	Not called
Secret configured, header mismatched	401	Not called	Not called
Matching header, mocked query returns zero schedules	200	Called	Not called

All four tests passed on Node.js v24.15.0, Vitest 4.1.4, and Next.js 15.5.15. The verification script accepts the source repository with its dependencies already installed:

node experiments/article-stock-2026-09/next-route-entry.mjs ../circle-hub-multi-device-push

This exercises the actual route function without starting a Next.js HTTP server. It uses the local environment-variable fallback. Cloudflare binding access, cron triggering, network requests, and real notification delivery are outside the test. The four cases do not test the Action transport either.

Even within that scope, invoking the entry point makes its conditions for reaching business logic observable. A test that checks only a 200 response would not reveal a missing rejection branch.

Reuse the logic behind the entry points

Suppose the same mutation later needs to serve both an admin screen and a mobile app. Instead of treating the Action as the external client's API specification, consider separating the common business function from its entry points:

Admin UI → Action → Session check ─┐
                                 ├→ Resource permission and input checks → Mutation
Mobile   → Route → API auth ──────┘

This is a proposed structure, not a refactoring completed on SquadNote's two entry points. The common function can receive an actor verified by server code or obtain the actor itself. A userId supplied in form data or JSON must not become a trusted actor merely because it was passed to that function.

If business authorization moves into the shared layer, every entry point must pass through it. The Action can retain form conversion and UI updates; the Route can retain HTTP input conversion and status selection.

The official Data Security guide also explains that a page-level authentication check does not extend to Actions defined inside the page. It shows authentication and authorization centralized in a data access layer invoked by the Action. A use server directive alone does not verify permission to operate on a resource.

Before choosing an entry point, write down the caller, credentials, input, and success and failure results. Choose an Action when these fit naturally into a screen operation, or a Route Handler when they need an independent HTTP contract. If reuse becomes necessary, extract the business logic while preserving those contracts.

Choosing Plane Projects, Modules, Cycles, and Initiatives by what needs to be finished

hiro@ — Fri, 18 Sep 2026 01:46:03 +0000

Trying to use every organizational level in Plane creates extra containers even when one person is building one feature. A more useful selection rule is to ask what kind of completion you need to check.

Use a Project for ongoing service maintenance, a Module for a feature or release, a Cycle for work within a period, and an Initiative for an objective spanning Projects. These do not need to form a mandatory linear hierarchy.

This is a design proposal based on Plane's official documentation checked on September 11, 2026, and SquadNote's multi-device push implementation. The inspected Workspace had its dedicated Initiatives feature disabled. SquadNote had zero non-archived Modules and zero non-archived Cycles. The arrangements below are proposals, not established operating practice.

Do not copy one change into four separate tickets

Multi-device push involves token registration, logout, recipient selection, and device reception checks. The repository collects its requirements in docs/multi-device-push.md, linked to SQN-49.

Using that work as an example, each organizational unit answers a different question.

Unit	Question	Possible arrangement
Project	Which service owns this work?	SquadNote
Module	Which deliverable must be complete?	Multi-device push support
Cycle	What will move forward during this period?	Registration API and logout implementation during a week in September
Initiative	What should several Projects achieve together?	Review notification operations across multiple apps

The last example is hypothetical. A change confined to SquadNote does not need an Initiative.

The design should not duplicate the same work into separate tickets for the Project, Module, and Cycle. One could become Done while the others retain stale states. Establish one Work Item for the actual work, then associate it with the organizational units that are useful.

Keep the Project as the ongoing maintenance home

The official Project documentation places Work Items, Cycles, and Modules inside a Project.

SquadNote will still need authentication and attendance maintenance after its push feature is complete. Finishing this feature and closing the entire Project are therefore different events.

"Is multi-device push finished?" and "Does SquadNote have unfinished work?" are separate questions. A single status cannot usefully answer both. The Project can remain in progress after a feature is finished because it is the continuing home for that product's work.

Give a Module deliverable-level acceptance criteria

The Module documentation describes grouping Work Items around features and other bodies of work. Modules can have start and due dates, and a Work Item can belong to several Modules.

If multi-device push becomes a Module, "improve notifications" would be too vague to establish completion. The implementation document supports more concrete criteria:

Preserve iOS and Android tokens for the same user at the same time.
Logging out on one device leaves the other device's registration intact.
Sending targets registered devices belonging to users with notifications enabled.
Record actual reception on the owner's test devices.

Completing only the first item should not close the Module. Saving a token on the server and receiving a notification on a device are different results.

If the feature also needs to be tracked as part of an application release, a feature Module and a release Module are an option. But a change small enough for one Work Item need not have a Module at all.

A Cycle's end date is not necessarily a feature's completion date

The Cycle documentation describes a time-bounded set of work. Unfinished Work Items can remain when the period ends and can be transferred to another Cycle.

Suppose registration and logout change this week, while device reception is checked next week. This week's Cycle ends, but the multi-device push acceptance criteria are still incomplete.

Closing the feature Module just because the Cycle ended would hide the pending device checks. Keep the Module's criteria and plan the unfinished verification in the next period.

Conversely, the fact that Modules can have due dates does not mean every weekly plan needs to be a Module. Choose based on whether you are naming a deliverable or deciding what to work on during a period.

Consider an Initiative when there is a shared objective

The Initiatives documentation describes tracking related Projects under a common objective. The page labels the feature Pro and provides instructions for enabling it.

The dedicated feature was disabled in the inspected personal Workspace. The MCP response also mentioned a Work Item type with the same name, but that is not evidence that the dedicated Initiatives feature is in use. Matching names do not establish matching capabilities or relationships.

As a design example, an objective as broad as "work on personal development" would not tell you which Projects to include or when to finish. "Standardize notification deregistration for the selected apps and complete reception checks for each" makes it possible to list the Projects and acceptance criteria. This illustrates when a shared objective could help; it does not claim that this cross-application work was performed.

Start with one Work Item

SquadNote's Project and a concrete Work Item already lead to its implementation document. Work was not blocked by the absence of Modules or Cycles.

Start with acceptance criteria in one Work Item. Consider a Module when related tasks grow and the deliverable needs its own completion view. Use a Cycle when planning and carryover across weeks become useful. Consider an Initiative once a specific objective requires judging several Projects together. This sequence is a proposal for the personal-development case examined here.

The effect of additional grouping on completion or sustained use has not been compared. A useful starting check is whether a ticket can clearly express this state: the API changes are complete, while reception on devices remains to be verified.

Implementation source: multi-device push requirements and verification criteria

Keeping Codex decisions in the repository and checking them against implementation evidence

hiro@ — Thu, 17 Sep 2026 01:58:33 +0000

During a long production effort, finding an old proposal is only part of the problem. You also need to know whether it was adopted, remains a target, or was superseded.

VOLT NOMAD's production documents include a decision log, plans for individual phases, and a release-candidate audit. Reading them at the same Git revision separates targets from verification results. This provides a concrete way to establish the current situation without relying on the last statement in a chat.

The source is events/2026-ai-browser-game-jam-4/ in game-jam-lab. Its documents and history at commit f074703 were inspected on September 11, 2026. An earlier production article covered the overall process; this one asks whether the next person can reconstruct a particular decision.

The original log records a choice and its reason

CHARGE_CLICKER_PRODUCTION_PLAN.md has a table of dates, decisions, and reasons. One entry dated August 2, 2026, chooses verification stages of 30 seconds, 5 minutes, and 20 minutes. Its stated reason is to avoid hiding a weak core loop behind more content.

When adding many features or assets becomes tempting, that entry provides the earlier criterion: establish that a short play session works first.

But the same table's targets of roughly 20 minutes for the normal ending and roughly one hour for the true ending remain targets. Being written down does not turn them into measurements.

Document statement	What it establishes	What it does not establish
A decision to verify in stages	The chosen verification approach at that time	Completion of every stage's tests
Targets of about 20 minutes and one hour	The intended experience duration at that time	A person's measured completion time
A date and reason	When and why the decision was made	That it remained unchanged afterward

A decision history is not an automatically current status report.

Check completion against later records

PROJECT_CHARGE_POLISH_PLAN.md in the same directory lists phase statuses such as implemented, music selection pending, and final QA in progress. Its stated update date is August 6.

RELEASE_CANDIDATE_AUDIT_2026-08-12.md, dated August 12, contains automated verification results. With the steady input model of 2 inputs per second, it records 15.58 minutes to the normal ending and 23.26 minutes for the complete route.

Comparing the original one-hour target with 23.26 minutes and declaring a major reduction would be premature. The latter uses automated input. The audit explicitly excludes time spent reading dialogue, understanding the interface, and comparing upgrades.

The relationship that can be reconstructed is:

Production plan: target duration of a person's experience
Release-candidate audit: automated result under a fixed input model
Human playthrough: a separate verification step

The automated playthrough was not rerun for this investigation. These numbers come from the saved audit, not a new measurement.

Fix a Git revision before reading across documents

Reading whatever happens to be in each working-directory file can mix in unfinished edits. For a technical explanation or article, pin the revision first.

git show f074703:events/2026-ai-browser-game-jam-4/docs/CHARGE_CLICKER_PRODUCTION_PLAN.md
git show f074703:events/2026-ai-browser-game-jam-4/docs/PROJECT_CHARGE_POLISH_PLAN.md
git show f074703:events/2026-ai-browser-game-jam-4/docs/RELEASE_CANDIDATE_AUDIT_2026-08-12.md

To investigate changes to a document, narrow the history to that file.

git log --oneline -- events/2026-ai-browser-game-jam-4/docs/CHARGE_CLICKER_PRODUCTION_PLAN.md

A commit date need not match a decision date in the document. Records can be added later. Check the text for the decision date and Git for changes to the record; neither should stand in for every event's timestamp.

The inspection confirmed that initial policy, intermediate phase status, and later audit results exist in separate documents. A "pending" status from August 6 cannot simply be copied into September's list of unfinished work.

Label the kind of fact a new entry records

The existing decision log uses date, decision, and reason columns. A proposed extension would include status and evidence.

## Decision: verify short play sessions first

- Status: adopted policy
- Decision date: 2026-08-02
- Reason: avoid hiding a weak core loop behind more content
- Evidence: decision log in CHARGE_CLICKER_PRODUCTION_PLAN.md
- Verification result: record separately from adoption of the policy

This example is derived from the existing record; the format has not already been adopted in the source files. Distinguishing a policy, implementation, and verification result does not require a new ADR management tool.

Silently replacing an old target with a new result also erases context. Preserve the previous target, the result under the current conditions, and the next question to check. A README or similar entry point can direct readers who only need the current policy to the current document.

Keeping a chat is different from being able to resume work

A chat can preserve the nuance behind a choice. There is no need to discard it. But when the next necessary decision exists only halfway through a conversation, someone still has to establish which code revision it applies to.

Repository documents become stale too. These materials contain plans and audits from different dates. Their mere existence does not complete a handoff.

On resuming work, establish what was chosen, what was implemented, and under which conditions it was checked. Preserve the files and commits that answer those questions. Do not reinterpret a target as a measurement or an intermediate plan as the latest completion report. This provides enough evidence to choose the next check without rereading every chat.

Sources: Production plan and decision log, release-candidate audit

What reversing a D1 composite index changes in the query plan

hiro@ — Wed, 16 Sep 2026 01:54:43 +0000

For a notification query using WHERE user_id = ? AND created_at >= ?, indexes on (user_id, created_at) and (created_at, user_id) do not behave identically.

In a local D1 comparison, the first plan showed both user and creation time as search constraints. The reversed index showed creation time alone. The experiment examines the planned search range. It does not measure response time.

Fix the query before comparing indexes

The example takes the user and creation-time fields from SquadNote's notification table and keeps only the necessary columns. It does not change an operational database or its indexes.

CREATE TABLE notification (
  id INTEGER PRIMARY KEY,
  user_id TEXT NOT NULL,
  created_at INTEGER NOT NULL
);

Consecutive integers stand in for timestamps. The fixture contains rows numbered 1 through 10,000, distributed across 100 users.

WITH RECURSIVE seq(n) AS (
  SELECT 1 UNION ALL SELECT n + 1 FROM seq WHERE n < 10000
)
INSERT INTO notification(id,user_id,created_at)
SELECT n, 'user-' || (n % 100), n FROM seq;

The SELECT stays unchanged:

SELECT id FROM notification
WHERE user_id = 'user-42' AND created_at >= 9000
ORDER BY created_at DESC;

user_id supplies equality, while created_at supplies a range and ordering. The question is which column order supports this query, not which column is more important in general.

Execute against Wrangler's local database

The experiment ran on September 11, 2026, using Node.js v24.15.0 and Wrangler 4.81.1. The SQL and configuration are included in the repository.

npx wrangler@4.81.1 d1 execute article-index-lab --local \
  --config experiments/article-stock-2026-09/d1-index/wrangler.jsonc \
  --file experiments/article-stock-2026-09/d1-index/compare.sql \
  --persist-to /tmp/article-stock-d1-index-lab --json

The SQL recreates the experimental table. --local and a dedicated persistence directory keep this separate from production. The configured database ID is a dummy value for local use. The official CLI reference documents --local and --persist-to.

An attempt to inspect the internal SQLite version with sqlite_version() was rejected in this environment. The internal version was not obtained.

Compare no index, equality first, and range first

The experiment prefixes the SELECT with EXPLAIN QUERY PLAN and swaps one index for the other.

CREATE INDEX idx_user_created ON notification(user_id, created_at);

The reversed definition is below. Both indexes were not installed together for the comparison.

CREATE INDEX idx_created_user ON notification(created_at, user_id);

The resulting detail fields were:

No index:
SCAN notification
USE TEMP B-TREE FOR ORDER BY

(user_id, created_at):
SEARCH notification USING COVERING INDEX idx_user_created (user_id=? AND created_at>?)

(created_at, user_id):
SEARCH notification USING COVERING INDEX idx_created_user (created_at>?)

Without an index, the plan scans the table and uses a temporary B-tree for sorting. (user_id, created_at) searches the time range within the selected user. The reversed index starts with the time range and applies the user condition as further filtering.

Although the plan displays created_at>?, both queries execute created_at >= 9000. Their returned IDs were checked too.

SQLite's Query Planning documentation explains ordering by the leftmost columns of a composite index. The difference here is whether equality fixes the first column before searching the time range within it.

Covering does not establish equivalent search ranges

Both indexed plans say COVERING INDEX. The query selects only id, and this table's INTEGER PRIMARY KEY aliases rowid. Being able to retrieve the needed values from the index does not mean the two indexes search the same range.

Do not conclude that reversing the index is equivalent simply because both plans are covering. Also read which constraints appear inside the parentheses after SEARCH.

Cloudflare's index documentation provides another starting point for checking an index against a query. Production rows read and billing effects were not measured here.

Check that the returned rows remain identical

Both indexed variants returned 10 rows with an ID sum of 94,920. Assertions also verified this exact ID sequence:

9942, 9842, 9742, 9642, 9542, 9442, 9342, 9242, 9142, 9042

This helps check that the SELECT has not accidentally changed while improving its plan. Different sets can share a count and sum, so this small result was compared directly as an ordered list of IDs.

The fixture has an artificial, even distribution. A production workload concentrated on particular users, or a query filtering only by time, needs its own assessment. The cost of maintaining indexes during writes was not compared either.

For this query, putting equality on user_id first produced a plan using both constraints for the search. For another query, compare the SELECT, query plan, and returned rows together instead of choosing by column names alone.

Tracing Android safe-area spacing to the components that apply insets

hiro@ — Tue, 15 Sep 2026 02:03:33 +0000

Before changing bottom spacing, find which components consume insets.bottom. A parent SafeAreaView and a child's paddingBottom can avoid the same area, potentially adding extra space even when the library reports correct values.

This is an investigation procedure based on reading SquadNote's code, not a report of reproducing and fixing a specific spacing bug on a device. The source is circle-hub commit 31e560d, using Expo SDK 54, React Native 0.81.5, and a react-native-safe-area-context declaration of ~5.6.0. It was inspected on September 11, 2026.

Separate OS conditions from application configuration

The Android documentation describes enforced edge-to-edge display on Android 15 or later when the application targets SDK 35 or higher. The target SDK matters as well as the device's OS.

SquadNote has edgeToEdgeEnabled: true in its configuration. Finding that setting does not establish that interactive controls avoid the system bars. Follow both the configuration that extends the background to the edges and the code applying insets to interactive areas.

System bars, display cutouts, and system gesture regions are also different categories. This React Native code uses the library's top and bottom insets. How those values change on a device needs separate checks with navigation mode and orientation controlled.

Distinguish the Provider from the View applying spacing

The relevant structure of authenticated screens is:

SafeAreaProvider
  View
    Header       → paddingTop: insets.top
    View / Stack → individual screens
    BottomNav    → paddingBottom: insets.bottom

Having a SafeAreaProvider is different from adding padding to every child screen. The library's official SafeAreaProvider and SafeAreaView documentation separates providing values from applying them as spacing.

BottomNav places the bottom inset outside a container with the navigation bar's own height.

const insets = useSafeAreaInsets();

return (
  <View style={[styles.container, { paddingBottom: insets.bottom }]}>
    <View style={{ height: layout.bottomNavHeight }}>
      {/* Navigation items */}
    </View>
  </View>
);

This excerpt keeps the layout from the implementation and omits the buttons and color definitions. Separating inner height from outer padding avoids changing the buttons' own height just to clear the bottom edge.

The public route group instead has no Header or BottomNav and wraps its Stack in SafeAreaView. Different route groups in the same application have different owners for safe-area spacing.

Trace the same edge when investigating double application

Suppose another SafeAreaView covering the bottom edge is added inside an authenticated screen. Whether spacing actually overlaps depends on Provider placement and the screen's region. Component names alone do not prove duplication. Check whether parent and child are both configured to avoid the same bottom-edge region.

For one target screen, collect:

Information	Where to inspect
The region against which insets are measured	Nearest SafeAreaProvider and its layout
Which edges are applied	SafeAreaView's `edges`
Manual additions	`paddingTop`, `paddingBottom`, and margins
Changes of region	Providers and layouts for modals or different routes
Actual values and rendering	Device insets, container boundaries, and button positions

In its normal additive mode, SafeAreaView adds insets to specified padding. For example, padding of 16 plus a bottom inset of 24 produces 40. Those are illustrative values, not measurements from a device in this investigation.

Choose whether to remove an edge or manual padding based on which component owns that edge. Subtracting a fixed value whenever spacing looks too large leaves assumptions that may fail with a different navigation mode or orientation.

Treat startup crashes separately from spacing

The working copy that prompted the investigation is named android-safe-area-hotfix. However, the actual fix changes the safe-area-context dependency declaration, lockfile, QA build configuration, and tests. It does not change inset or padding code.

Rerunning its focused tests with Node.js v24.15.0 and Vitest 4.1.4 passed both tests. They check the dependency declaration and QA configuration.

pnpm --filter @squadnote/mobile exec vitest run src/lib/android-native-runtime.test.ts

Passing those tests does not establish correct screen spacing or guarantee that a native startup crash will not recur. If the app crashes before the screen opens, inspect the native error first. If the screen opens with misplaced content, trace where spacing is applied.

Authenticated and public routes assign inset handling to different components. Select the target route, identify who handles its bottom edge, then compare that implementation with the values and positions on a device.