title: "Briefing — "What should we investigate?"" source: "tasks/TFW-52__tfw_light_v1/research/iter2/1_briefing.md"

Briefing — "What should we investigate?"¶

Mindset: Strategist. You're planning an investigation, not doing it. Frame what matters. Resist solving. Test: "Can I explain WHY we're investigating this and what would change our approach?" Parent: HL-TFW-52 Goal: Determine the smallest reliable Assisted mechanisms for discipline, collaboration, identity, and durable memory while preserving Light's simplicity and the approved edition boundary.

Iteration Context¶

This is iteration 2 in DEEP mode. It is bounded to the owner-approved focus “Assisted enforcement, collaboration, and memory” and tests H1–H4. The approved master HL and its plan are immutable in this Researcher session.

Predecessor: iteration 1 RES.

Predecessor item	What iteration 2 carries forward
CH-D1	Hidden sibling directories are not a valid active runtime topology; they may be inactive sources, archives, caches, or fixtures only. Wrong-root discovery is therefore a bounded Assisted validation scenario, not a renewed topology program.
CH-D2	X1 visible contract, X2 independent packages, and X3 hybrid core/overlays remain conditional topology survivors. This iteration does not choose among them.
CH-D4	Active authority/version and explicit conflict/receipt behavior are necessary alongside semantic preservation. Root checks, consolidation authority, recovery, and provenance will use this constraint where relevant.
CH-D5	Broad claims require bounded wording and executed evidence. H1–H4 will distinguish official support, local observation, unavailable mechanisms, and proposed adapter behavior.
RES-D1	Iteration 1 concluded MORE NEEDED. The new owner direction assigns iteration 2 to H1–H4 rather than the predecessor's proposed broad M1–M5 topology/evolution program.

Predecessor open threads are handled as follows: OT1 contributes only wrong-root and active-authority fixtures; OT2 and OT3 remain deferred because X1/X2/X3 economics and neutral product-line contracts are outside this iteration; OT4 remains deferred; OT5 contributes only the Assisted consolidation behavior assigned under H2–H3, not Light pedagogy or a redesign of the edition spine.

Research Plan¶

Gather¶

Establish a source hierarchy led by current official OpenAI/Codex documentation, then inspect actual local configuration and behavior with read-only checks or disposable fixtures. Classify every H1 mechanism as documented support, observed local behavior, unavailable/not evidenced, or proposed Assisted adapter behavior.
Inventory session-start instruction loading, project/root and AGENTS.md discovery, pre-compaction/checkpoint, stop/completion controls, hooks, automations/scheduled tasks, skills, and memories. Record platform/surface/version constraints instead of inferring parity across Codex desktop, CLI, and other surfaces.
Compare H2 lazy catch-up with calendar scheduling: closed-app/computer states, external-scheduler requirements, staleness markers, idempotence, missed-run recovery, and the smallest quiet user interaction.
Build a disposable Google Drive-style synchronized-folder model for H3 without touching real Drive. Exercise 2–3 writers, unique append-only candidates, duplicate meaning, one/two consolidators, conflict copies, interruption, stale lease, rebuild, and recovery.
Model H4 identity inputs and privacy boundaries for one/multiple profiles, device-local bindings, new devices, unknown/stale bindings, renamed participants, and authorship provenance; include ordinary non-work conversations and risk-category routing.

Extract¶

Decompose the decision space into at least these dimensions: lifecycle event/support surface, root/instruction authority, catch-up execution model, staleness state, candidate naming/idempotence, consolidator ownership/lease, record/index authority, identity selection/binding, provenance, and risk/no-task policy.
Produce a lifecycle contract matrix that keeps official guarantees, local observations, absent features, and adapter proposals separate; map each viable event or fallback to the specific Assisted invariant it can actually enforce.
Produce an H2 state/interaction table covering Codex open/closed, computer awake/offline, internal automation/external scheduler, overdue detection, retry, and user-visible output.
Derive an H3 protocol and recovery state machine from fixture results, including append-only uniqueness, semantic deduplication, two-consolidator exclusion, atomic publication/checkpoints, conflict-copy intake, stale-lease stealing, full index rebuild, and interrupted-run recovery.
Derive the smallest H4 identity state machine and risk gate that preserve authorship/privacy without shared CURRENT_USER; separately validate that Light → Assisted and wrong-root scenarios do not become a topology redesign.

Challenge¶

Attack H1 with stale-session, wrong-root, nested-root, missing-event, duplicate-event, compaction-without-callback, premature stop, ordinary-question, and unsupported-surface scenarios; seek evidence that text-only or fewer mechanisms are sufficient.
Attack H2 with Codex closed, machine asleep, long absence, clock skew, corrupted/missing state, repeated launches, simultaneous schedule and catch-up, and no external scheduler; compare catch-up-only as the simpler baseline.
Attack H3 with simultaneous candidate creation, identical semantic content under different IDs, ID collision, two consolidators, stale/false lease ownership, Drive-style conflict copies, partial record publication, corrupt derived index, rebuild, and recovery; compare simpler lease-free or rebuild-only designs.
Attack H4 with one profile, multiple profiles, new device, unknown user, stale binding, renamed/deleted participant, copied local state, privacy leakage, and disputed authorship; compare session-local selection and OS-local binding alternatives.
Cross-check Windows and cross-platform constraints, task-local trace/status/owner consistency, secrets and sensitive/high-stakes categories, non-work conversations, and quiet weekly behavior. Report HL confirmation, contradiction, unresolved evidence, and any exact proposed owner-approved diff separately; apply none.

Hypotheses (from HL §10)¶

#	Hypothesis	HL Status
H1	`SessionStart` + pre-compact checkpoint + `Stop` can reliably make Assisted load context, maintain a trace, and align status without persistent questions.	open
H2	Lazy weekly catch-up at the first later start provides practically similar memory freshness to a calendar schedule without requiring Codex to remain running.	open
H3	Unique append-only candidates + one consolidator + a derived index prevent knowledge loss for 2–3 participants sharing a Drive-style synchronized folder without Git.	open
H4	`1 profile → auto; >1 → device-local binding/one question` establishes authorship reliably without a shared `CURRENT_USER`.	open

Scope Intent¶

In scope: H1–H4; official current Codex contracts and safe local behavior checks; current repository Codex adapter; TFW-51 as the Light baseline; bounded root-discovery and Light → Assisted preservation fixtures; lazy catch-up versus scheduling; disposable Drive-style concurrency models; identity, provenance, privacy, risk gates, non-work conversations, task-local consistency, Windows and cross-platform constraints; counter-evidence and smaller alternatives.
Out of scope: modifying the approved HL or its plan; selecting or redesigning the X1/X2/X3 product topology; broad edition/source-layout redesign; Team/session-role research assigned to iteration 3; real Google Drive access; product implementation; adapter changes; TS/code; Task Board or iterations.yaml updates; any write outside research/iter2/.

Guiding Questions¶

Which Assisted lifecycle behaviors are officially supported and locally observable today, and which must be honest adapter fallbacks rather than claimed Codex guarantees?
What is the smallest catch-up and single-consolidator protocol that stays correct under missed schedules, concurrent writers, duplicate inputs, conflict copies, interruption, stale leases, and rebuild?
What identity and risk UX minimizes questions while preserving privacy, authorship provenance, task ownership, and ordinary non-work conversation behavior?

User Direction¶

Run TFW-52 research iteration 2 in DEEP mode as a separate Researcher session, testing H1–H4 under the approved focus “Assisted enforcement, collaboration, and memory.”
Treat the approved master HL and plan as immutable. Findings may confirm, challenge, or recommend a transparent diff, but Researcher applies no recommendation.
Write only research/iter2/1_briefing.md, 2_gather.md, 3_extract.md, 4_challenge.md, and RES.md; no commits, staging, product implementation, real Drive access, or external writes.
Root discovery and Light → Assisted preservation are bounded validation scenarios inside Assisted research, not a replacement research program.
At every WAIT/STOP checkpoint, write the stage file first, report concise findings and at most three blocking questions, request coordinator authorization, and stop.
Final RES must separate Confirmed HL, Challenged HL, Unresolved, and Recommended owner-approved changes, and must return final status plus [ITERATION_COMPLETE] to the coordinator thread.

Briefing Checkpoint¶

Stage plan complete: YES — Gather, Extract, and Challenge each have explicit evidence targets and counter-evidence paths.
Scope bounded: YES — H1–H4 only; topology, Team, and product changes are excluded.
Predecessor incorporated: YES — CH-D1/D2/D4/D5, RES-D1, and OT1–OT5 disposition are explicit.
Mode requirements planned: YES — official external sources, safe local/fixture evidence, hypothesis tests, counter-evidence, and up to three OODA loops per later stage.
Blocking questions: None.
Recommendation: Close Briefing and authorize Gather.

Stage complete: YES Coordinator record: Briefing accepted on 2026-08-08; Gather authorized.