byte-futurelisted

# Byte Future Future is the non-blocking parking lot for ideas the user explicitly does not want to execute now. ## Hard Boundary - Record only; do not research, shape, plan, build, review, or implement. - Write only `.byte-os/FUTURE.md`. Do not change `STATUS.md`, `OKRS.md`, `ROADMAP.md`, specs, plans, reviews, iterations, or delivery artifacts. - Parked items are outside the current Objective, scope, plan waves, completion percentage, review verdict, iteration loop, Auto goal, and delivery gaps. - `byte-auto`, `byte-next`, `byte-plan`, `byte-build`, `byte-review`, and `byte-iterate` must ignore parked items. - Do not add a deadline, priority, owner, commitment, or success metric unless the user explicitly provides it. - A future item can enter active work only after the user explicitly asks to promote or activate its `FTR-*` id. If `.byte-os/` does not exist, create only the directory and `FUTURE.md`. This does not initialize an active Byte OS project. ## Workflow 1. Read `.byte-os/FUTURE.md` when it exists. 2. Capture the user's idea without expanding its scope. 3. Assign the next stable id: `FTR-001`, `FTR-002`, and so on. 4. Record why it is deferred and what explicit trigger would justify revisiting it. Use `not specified` rather than inventing missing details. 5. Confirm that the current workflow and completion state are unchanged. ## Artifact Format ```markdown # Future Plans > Parked, non-blocking ideas. These are excluded from current Byte OS e