Phase 0: campaign skeleton, research question pending

Spun off 2026-05-03 from the closed-without-patch
kwin_overlay_subsurface campaign (its phase8_handover.md is
the predecessor). The candidate research question is whether
running an X11 session on PineTab2 reproduces, eliminates, or
transforms the drop-inversion phenomenon that motivated the
predecessor — but the framing is provisional and awaits
operator confirmation before Phase 1 lock.

phase0_findings.md is the substrate doc:
- Predecessor close-out summary (three reasons no patch
  landed; replicate-baseline-first lesson).
- What stays valid from the predecessor (Phase 1 scanout
  archaeology, Phase 2-prime KWin Wayland source-read which
  does NOT transfer to X11, Δ_present-46ms reproducible
  side-finding which is directly testable under X11,
  measurement infrastructure with WAYLAND_DEBUG-specific
  parts that don't transfer).
- Current ohm state (carry-over predecessor tooling, governor
  pin, baloo disabled, kwin-fourier still installed).
- Provisional research question with three plausible
  outcomes (α/β/γ) and four alternate framings the operator
  may have in mind that this question doesn't cover.
- Working-assumption out-of-scope list (no patches, no MRs,
  no Δ_present chase yet).
- Four pre-question Phase 0 deliverables that are unblocked
  regardless of framing: ohm state snapshot, X11-path
  inventory, X11 measurement-tool inventory, A1
  Wayland-baseline rep on this campaign's session for future
  comparison anchor.

worklist.md tracks Phase 0 only. Phase 1 lock awaits the
research question. Discipline carry-overs from
kwin_overlay_subsurface listed (replicate baseline first;
phase discipline; non-upstreaming default; memory
persistence at close).

README.md status banner: Phase 0 in progress, research
question pending operator confirmation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-03 06:38:24 +00:00
commit eff6fb5b29
4 changed files with 349 additions and 0 deletions
+55
View File
@@ -0,0 +1,55 @@
# Work items — x11-session-research
## Phase 0 — substrate + research question framing
**Status: IN PROGRESS.** Substrate doc landed
(`phase0_findings.md`). Research question is provisional,
awaits operator confirmation. Pre-question Phase 0 deliverables
listed below are unblocked.
- [x] Predecessor close-out summarised. Substrate doc
(`phase0_findings.md`) lists what stays valid from
`kwin_overlay_subsurface`, what's specific to Wayland and
doesn't transfer, and three plausible outcome shapes (α/β/γ)
for the candidate research question.
- [ ] **Operator confirms the research question.** Three
candidate framings + four alternates are listed in
`phase0_findings.md` § "Research question (provisional)".
Pick one (or correct the framing) before Phase 1.
- [ ] State snapshot of ohm under current Plasma Wayland —
the campaign-start *before* photo. Unattended-tractable.
- [ ] Inventory of available X11 paths on ohm: installed
packages, SDDM-advertised sessions, alternate WMs,
XWayland availability. Read-only.
- [ ] Inventory of measurement instruments that work under
X11. `xtrace`, frame-timing tooling, perf on Xorg PID, etc.
Read-only.
- [ ] A1 baseline: 1× `kwin_timing_nodebug`-equivalent run
on current Plasma Wayland session, captured into
`phase0_evidence/wayland_baseline_rep1/`. Same-session
anchor for any future X11 comparison.
## Phase 1 — locked research question + binding cells
**Pending operator confirmation of the Phase 0 question.**
Phase 1 lock will produce `phase1_lock.md` with binding cells
specific to whichever framing is locked.
## Phase 2-onwards
Pending.
## Discipline carry-overs from `kwin_overlay_subsurface`
- *Replicate the baseline first* — per
`feedback_replicate_baseline_first.md`. Phase 0 task "A1
baseline" exists specifically because of this lesson; do not
skip it.
- *Phase discipline* — no patches before source-read is
documented. Re-scoping must be honest about deferral target.
- *Non-upstreaming default* — bug reports + MRs are explicit
operator-tasked decisions.
- *Memory persistence rule* — when this campaign reaches its
diagnostic terminal state (success or honest closure), update
`project_campaign_overview.md` and add any new feedback
memory worth carrying forward to the next campaign.