English · 日本語

This document tracks features planned for future implementation. Each item has its own file (one BE ID per item). Add unformed thoughts to Unsorted ideas first, then promote them to a numbered item once the scope is clear.

• The accurate list of what exists today (implemented / unwired) is in architecture.md#implementation-status — the source of truth. This page covers what is planned next.
• The design rationale is in DESIGN.md.
• The overall strategic direction is in vision.md.

Priority — P0 (do next) / P1 (will do) / P2 (nice to have) / P3 (idea stage) Status — 💡 idea / 📋 planned / 🚧 in progress / ❄️ on hold / ✅ done

Every roadmap item is a directory roadmaps/BE-NNNN-<slug>/ holding the English file BE-NNNN-<slug>.md and its Japanese version BE-NNNN-<slug>-ja.md (same ID and slug). BE stands for Bajutsu Evolution and NNNN is a zero-padded, 4-digit, monotonically increasing ID. Every item lives directly under roadmaps/ in a flat layout: its path is fixed the moment its ID is allocated and never moves (BE-0159 retired the per-Status folders BE-0078 introduced). Status is the single source of truth for the index bucket an item lists under — it no longer decides the item's location.

When you add a roadmap item:

1. Allocate the next ID = the highest existing BE-NNNN + 1, over every item under roadmaps/. Find it with:

   ls -d roadmaps/BE-*/ | sort | tail -1

   Never reuse, skip, or guess a number. The norm, though, is to leave it undetermined: name the item BE-XXXX-<slug> (the literal placeholder) and let CI assign the number. The item keeps BE-XXXX through review and the merge, and the roadmap-id workflow runs scripts/allocate_roadmap_ids.py on main after the PR merges, allocating the next free IDs in merge order and committing the rename to main (BE-0089). This is what the ideation skill does; it keeps the BE-NNNN sequence contiguous (a rejected PR never spends a number) and avoids two in-flight branches racing for one. A BE-creation PR therefore carries no [BE-NNNN] title prefix — the real number is not known until after the merge.
2. Create the item directory and both language files — Status: Proposal for a proposal, or Status: Implemented when the same PR also ships the implementation (a new item is a proposal first unless its code lands with it) — at roadmaps/BE-NNNN-<slug>/BE-NNNN-<slug>.md (English) and roadmaps/BE-NNNN-<slug>/BE-NNNN-<slug>-ja.md (Japanese, same ID & slug). Don't hand-edit the index tables below — they are generated from each item's own metadata. Run make roadmap-index (or python scripts/build_roadmap_index.py) to regenerate the tables between the <!-- GENERATED:* --> markers in both index pages. The item's Status (its bucket) + Topic decide its section, so an item in an existing section needs no manual table edit; the gate (tests/test_roadmap_index.py, run by make test) fails if the committed index drifts. The first item of a topic to reach a bucket needs a new marked section in the page (the generator names the missing region).
3. IDs are permanent. Never renumber an existing item — not when its status changes, not when it is completed, not when it is removed from a table. A BE ID, once assigned, refers to that item forever.

Each file follows the Swift-Evolution proposal format: a metadata block then ## Introduction / ## Motivation / ## Detailed design / ## Alternatives considered / ## References (fill what you can; mark unknowns TBD). The metadata is a fenced | Field | Value | table — <!-- BE-METADATA --> … <!-- /BE-METADATA -->, opening with a | Field | Value | header row (| 項目 | 値 | on the Japanese side) and holding Proposal, Author, Status, Topic (plus Implementing PR once shipped and Origin last, when applicable); the Japanese mirror uses 提案, 提案者, 状態, トピック. Name the author by GitHub handle — | Author | [@handle](https://github.com/handle) |, the account of whoever first authored the item (for an AI-assisted draft, the person who drove and committed it). tests/test_roadmap_format.py checks this shape. The Status decides only the index bucket: Implemented / In progress / Proposal / Proposal (deferred). When an item's status changes — it starts being built, or it ships — set its Status and regenerate the index (make roadmap-index); the item stays in its original directory (BE-0159), and the table moves it to the matching bucket automatically.

Write the Japanese file (*-ja.md) in 敬体 (the polite desu/masu style, ですます調), consistent with docs/ja/ — never the plain da/dearu style (常体). This is part of the japanese-tech-writing norm; a translation must read as natural polite Japanese, not a literal rendering of the English.

Shipped — landed on main. This is the project's implementation record.

One backend per platform behind the single driver interface (DESIGN §1) — the iOS Simulator (idb / XCUITest actuators), Android (adb), the web (Playwright), and Flutter — plus the on-device validation that keeps each backend's actuation faithful. Going multi-platform means adding backends, not changing the deterministic core. Overview: multi-platform.md.

The backend-agnostic core every platform plugs into: the driver interface and its conformance suite, the capability model and preflight, the wait_for polling contract, backend lifecycle, and per-target / per-platform config resolution.

What a scenario can express: variables and light control flow, data-driven runs, tags and selective runs, secret variables, reusable parameterized steps, HTTP / OTP / email side-channel steps, and device / OS-state control steps (background, status bar, timezone, clipboard, shake, location).

How a run decides pass or fail — deterministically, and often below the UI: behavioral / protocol assertions, visual-regression assertions and their compare engines, the determinism / flakiness audit, and the E2E coverage map. The deterministic runner these build on landed first.

The AI-driven record (Tier 1) is implemented (recording.md). These items make the record → edit → re-run cycle easier for humans; the local web UI launcher bajutsu serve is the first step.

Autonomous exploration that maps an app's screens on its own, kept fast and resumable: parallel crawl across simulators and browsers, web crawl, and full-frontier continuation.

Turning a passing scenario into a native test in a destination framework's idiom — XCUITest, Playwright, and Android (Espresso / UI Automator).

Lower the maintenance cost of regressions while keeping AI out of the judge role and limited to an investigator.

Sending a run's result out to a service the team already lives in — post-verdict, deterministic transports that carry the verdict the runner computed, never an LLM's.

The Tier-1 AI paths (record / triage / --dismiss-alerts / crawl) call Claude through a pluggable provider. This topic covers selecting and configuring that provider — e.g. Amazon Bedrock (authenticated with AWS credentials) as an alternative to the direct Anthropic API — and the provider-agnostic, redacted AI data path. The deterministic run / CI gate calls no model and is unaffected.

Making Bajutsu's AI token and dollar spend visible: an attributed, persistent ledger of every AI call, and (separately) the serve Web UI dashboard that reads it.

Bringing the CLI's own tools into the serve Web UI, where authoring happens. The scenario editor's inline lint / schema validation landed first.

Standing up bajutsu serve beyond loopback. The hardening that makes the existing stdlib server safe to expose (auth, input validation) has shipped; the full hosted topologies remain proposals below.

Where a project's config and scenarios come from. A Git repository + ref is a today-runnable source for CI and a self-hosted serve, materialized at an immutable commit.

Closing the edges the deterministic core does not touch — serve's HTTP surface, how secrets flow through capture / record / artifacts, driver argument hygiene, and the CI supply chain. These items keep the tool safe to run on a shared machine and safe to hand a scenario from an untrusted source, without weakening the prime directives.

Purpose-built test subjects that exercise the commands end-to-end. The showcase suite is the iOS dogfood target — the same app in UIKit and SwiftUI, each in an accessibility-on / accessibility-off variant — so run, record, doctor, and crawl all have one rich, representative subject. The screen-by-screen contract lives in demos/showcase/SPEC.md.

Bajutsu's own serve Web UI is a web app, so the Web (Playwright) backend drives it — a deterministic, Tier-2 regression net for the UI, the web-side counterpart to the iOS showcase fixtures.

Reduce friction for the many parallel sessions working this repo — treat merge conflicts as a design smell and reshape the file flow so independent changes touch disjoint files.

Behavior-preserving cleanup inside bajutsu/ itself — deduplication, decomposition of oversized functions/modules, and naming clarity — as distinct from Development infrastructure (contributor workflow) above, which covers the tooling contributors use to work on this repo (CI, hooks, roadmap automation).

Accepted and actively being built — a PR is in flight or imminent.

Under consideration — not yet decided. Promote an item to In progress once work starts, or to Implemented when it ships.

Running a scenario on a hosted device farm instead of a local Simulator, emulator, or browser, behind a common provider abstraction — an opt-in execution target beyond the deterministic core's local-first default.

Parked proposals — considered, then shelved for now. Kept here (not deleted) so the decision and its rationale stay on record; un-defer by changing Status back to Proposal.

• Change history / version management — already covered, since scenarios are YAML under git.
• Cloud device farm / real-device execution as the default — the deterministic core stays local-first and CI-friendly (Simulator, headless browser, emulator), not real hardware or device clouds (DESIGN §1). Hosted device-cloud execution is not the default, but it is no longer flatly out of scope: it is tracked as opt-in proposals under Device-cloud execution. Multi-platform likewise lives under the Platform support items.
• Per-step screenshots / UI tree on error / device logs — already covered by the evidence subsystem (capturePolicy + the result:error safety net).
• NL→test generation (Autopilot equivalent) — overlaps with the existing record + the Authoring experience items.
• Scheduling / Slack / TestRail integration — the domain of the CI / notification layer. Low priority (separately, if needed).
• Automatic retry of failed tests — in tension with determinism-first (no fixed sleeps, condition waits). It can hide flakiness, so if adopted at all it should be limited to quarantine use and needs careful consideration.

Add unformed thoughts here. Promote them to a numbered BE item later.