PawWork users on their own provider keys should not silently inherit
global Claude Code instructions as their PawWork baseline (issue #230,
acceptance #5). Gates the fallback push behind a Runtime.isPawWork()
check so the existing opt-out flag still works for plain opencode CLI
users; project-level CLAUDE.md remains as compatibility (#6).

The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME
can stub the home directory deterministically — Bun's os.homedir() is
locked at process start, which would otherwise make the global Claude
path untestable under Bun's test runner.

Tests cover the five scenarios from acceptance #8: fresh install, project
AGENTS.md, project CLAUDE.md compatibility fallback, PawWork global
AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A non-PawWork
regression test guards the Runtime.isPawWork() gate so an accidental
condition inversion would fail the suite.

…awWork mode

CodeRabbit caught two follow-on gaps in the previous batch.

OPENCODE_DISABLE_CLAUDE_CODE_PROMPT was still gating the project-level
FILES list, which meant a PawWork process inheriting that env var would
silently drop project-level CLAUDE.md compatibility (issue #230,
acceptance #6). Extracts a pure projectFiles({ isPawWork,
disableClaudeCodePrompt }) helper so the gate is testable without
mutating module-scope flags, and gates CLAUDE.md inclusion on
isPawWork || !disableClaudeCodePrompt — PawWork mode keeps the project
fallback regardless of the flag, plain opencode CLI still respects it.

systemPaths() expanded ~/ in config.instructions via os.homedir() while
sources() expanded the same entries via Global.Path.home, so a
config.instructions entry like ~/rules.md could read from one path in
the prompt and report a different path in diagnostics. Both sites now
route through Global.Path.home; os import is no longer needed.

Tests: four projectFiles cases covering PawWork × flag matrix; the
existing project CLAUDE.md test continues to verify the runtime path
through systemPaths().

PawWork users on their own provider keys should not silently inherit
global Claude Code instructions as their PawWork baseline (issue #230,
acceptance #5). Gates the fallback push behind a Runtime.isPawWork()
check so the existing opt-out flag still works for plain opencode CLI
users; project-level CLAUDE.md remains as compatibility (#6).

The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME
can stub the home directory deterministically — Bun's os.homedir() is
locked at process start, which would otherwise make the global Claude
path untestable under Bun's test runner.

Tests cover the five scenarios from acceptance #8: fresh install, project
AGENTS.md, project CLAUDE.md compatibility fallback, PawWork global
AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A non-PawWork
regression test guards the Runtime.isPawWork() gate so an accidental
condition inversion would fail the suite.

…k mode

PawWork users on their own provider keys should not silently inherit
global Claude Code instructions as their PawWork baseline (issue #230,
acceptance #5). Gates the global fallback push behind a
Runtime.isPawWork() check so the existing opt-out flag still works for
plain opencode CLI users; project-level CLAUDE.md remains as
compatibility (acceptance #6) and is unaffected here.

The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME
can stub the home directory deterministically — Bun's os.homedir() is
locked at process start, which would otherwise make this code path
untestable under Bun's test runner.

Tests cover the five fallback scenarios from acceptance #8: fresh
install, project AGENTS.md, project CLAUDE.md compatibility fallback,
PawWork global AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A
non-PawWork regression test guards the Runtime.isPawWork() gate so an
accidental inversion would fail the suite.

… of disable flag

A PawWork process inheriting OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1 from
a parent shell would build the project FILES list without CLAUDE.md and
silently drop the project-level compatibility fallback that issue #230
acceptance #6 explicitly preserves.

Extracts a pure projectFiles({ isPawWork, disableClaudeCodePrompt })
helper so the gate is testable without mutating module-scope flags, and
gates CLAUDE.md inclusion on isPawWork || !disableClaudeCodePrompt:
PawWork mode keeps the project fallback regardless of the flag, plain
opencode CLI still respects it. The runtime FILES() function reads
process state at call time so tests that flip Runtime.isPawWork() pick
up the new behavior immediately.

Tests cover the four-case matrix on the helper directly, providing
deterministic coverage for both axes.

… changes

AstroHan flagged in the second W1 retest that scrolling away from the
bottom and then nudging again would yank the viewport back to bottom.
GPT-X's systematic debugging report (msg=bd9c5ed8) traced the bug to
three independent gaps across the timeline's scroll-owner stack —
addressing any one alone is not enough, so this commit applies the
minimal-archetype trio.

1. `session-timeline-scroll-controller.ts` `observe()` — when a
   scroll_sample arrives in `following_latest` mode but the viewport
   is no longer near the bottom, and the last user intent was a
   non-nested wheel/touch, demote to `reading_history` here. The
   previous `weak_scroll_observed` fall-through left mode stuck in
   `following_latest`, which the later `mode === "following_latest"`
   branch turned into a `restore_latest` recovery on every subsequent
   observation — i.e. the snap-back the user was seeing.

2. `use-session-timeline-interaction.ts`
   `shouldCancelBottomFollowLockForIntent()` — release the
   bottom-follow lock on every non-nested wheel/touch, not just
   upward ones. The previous gate left the 3-second lock armed after
   a downward nudge, so a later content resize would call
   `followBottom()` against the user's actual position.

3. `message-timeline.tsx` `onScroll` — run the gesture-driven path
   (`onUserScroll` / `onAutoScrollHandleScroll` / `onMarkScrollGesture`)
   *before* `onScheduleScrollState`. The previous order meant
   `scheduleScrollState` saw a stale `bottomFollowLocked()` and called
   `followBottom()` on the same frame, before the gesture could mark
   `userScrolled`.

The "彻底" alternative (merge `createAutoScroll`, `use-session-scroll-dock`,
`session-timeline-scroll-controller` into a single state machine) is
tracked as issue #595 and stays out of this PR.

If this trio is still not enough, the next step is the #595 refactor —
do not chain more timing/threshold guesses on top.