title: "Briefing — "What should we investigate?"" source: "workspace/2026/TFW_20260830-114238_ASSISTED15/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_20260830-114238_ASSISTED15 Predecessor: Iteration 1 RES Goal: Convert iteration 1's surviving P2×R1 design and mandatory P2×R2/P6×R1 fallbacks into fixture-ready constraints for Assisted 1.5 without reopening the frozen product contract or broadly re-reading the field lineage.

Research Plan¶

Gather¶

Build a primary-source decision ledger for locality on Windows, macOS, and Linux: candidate location, volume/mount evidence, provider/shared-root evidence, link/reparse defense, permissions, safe primitive availability, and the exact proven | unsafe | unknown outcome.
Compare deterministic serialization options and derive fixture inputs for three separate records: public release manifest, ordered maintenance policy, and per-operation report. Include canonical path handling, duplicate/collision rejection, transition binding, partial-write journaling, sensitive-field suppression, and clean versus mixed lineage fixtures.
Inspect only the targeted template surfaces necessary to define a neutral offline theme/asset interface and render matrix; do not repeat the broad field inventory.
Map the minimal reusable-role adapter capabilities to current official OpenAI/Codex evidence and an explicit manual fallback, including interruption and same-session retry behavior.
Construct a minimal public 1.0/1.5 history/privacy fixture and enumerate false-history/private-leak attacks without copying downstream release facts.

Extract¶

Cross-reference the five threads into implementation-ready alternatives: conservative locality tables, schema/serialization families, stock/theme overlay interfaces, adapter state machines, and public-history forms.
Select field names, enums, default-deny rules, transition states, report redactions, and fixture assertions that can carry V1–V12 into TS without embedding a specific corporate path or runtime.
Separate positive evidence from absence of evidence. In particular, test whether fixed/local volumes, canonical JSON, successful HTML generation, available task creation, or marker-free prose actually establish the stronger claim being made.
Produce exact surviving contracts plus mandatory fallback behavior; keep implementation language choices provisional unless primary evidence makes one necessary.

Challenge¶

Attack locality with local cloud-sync folders, network homes, reparse/symlink ancestor swaps, permissive parents, unsupported probes, stale locks, and zero-write verification.
Attack schemas with duplicate keys, raw-versus-normalized strings, case/Unicode collisions, rule overlap, stale/mixed release data, sensitive paths/hashes, changed baselines, and failure after the first mutation.
Attack templates with offline mode, missing/custom assets, external URLs, metadata leaks, long Cyrillic/Latin content, pagination overflow, customized-old-template preservation, and renderer variation.
Attack orchestration with partial capability sets, lost sessions, failed targeting, duplicated role sessions, writer overlap, incomplete re-review, and reports sent outside the coordinator.
Attack history with invented dates, SemVer claims, tag dependency, downstream versions presented as public, provenance wording that leaks facts, and changelog/version disagreement.

External Orientation for This Briefing¶

RFC 8785 supplies deterministic JSON canonicalization but explicitly preserves string data rather than applying Unicode normalization. Therefore JSON canonicalization and portable path identity must be investigated as separate layers: RFC 8785.
Windows exposes fixed versus remote drive classes, while Linux exposes mount point, filesystem type, and source through /proc/<pid>/mountinfo. Neither fact alone proves absence of a user-space synchronization client, so Gather must distinguish positive signals from conclusive locality: Microsoft GetDriveTypeW, Linux kernel proc documentation.
W3C paged-media guidance explicitly permits renderer-dependent behavior and content outside the page box. A successful HTML build is therefore counter-evidence to treating exit status as readability proof: CSS Paged Media Level 3.

Hypotheses (from updated HL §10)¶

#	Hypothesis	HL Status entering iteration 2
H1	Universal lifecycle and identity behavior can be extracted without weakening fail-closed safety	supported with refinement; positive locality proof or zero-write session fallback
H2	A classified manifest plus non-mutating comparison can support safe forward update and reviewed reverse promotion without a mirror	conditionally supported as release manifest + maintenance policy + operation report; mixed lineage starts with P6
H3	Practical templates can be neutralized while preserving result-producing logic	structurally supported; offline render and customization evidence pending
H4	Russian remains the 1.5 authority while English localization stays separate	supported for 1.5

Counter-Evidence Targets¶

A DRIVE_FIXED or locally mounted filesystem may still be synchronized, so the locality table may have fewer proven defaults than convenience suggests.
JCS may make schema bytes deterministic while leaving portable filename normalization, rule precedence, and semantic authority unresolved.
One reusable role session may be impossible in a runtime that supports task creation but not stable follow-up/observation; manual mode must remain complete rather than partially autonomous.
A changelog can avoid copying content yet still leak private path names, hashes, dates, or false release relationships.

Scope Intent¶

In scope: the five iteration-2 threads from iterations.yaml; targeted repository reads; official primary-source verification; fixture and schema design; counter-evidence; refinement/amendment classification; implementation-facing V1–V12 constraints.
Out of scope: another broad field-lineage inventory; editing HL, status, iterations.yaml, product files, Full TFW, or Light; executing public implementation; copying downstream facts; weakening frozen DoD/DoF; push or tag.

Guiding Questions¶

What exact evidence and data model let each platform return proven, unsafe, or unknown without converting a heuristic into a promise?
What smallest deterministic manifest/policy/report and template/history fixtures make P2/P6, privacy, offline rendering, and partial-failure behavior mechanically testable?
What capability transaction preserves one reusable session per role, full independent re-review, coordinator-only reporting, and a complete manual fallback across supported runtimes?

User Direction¶

Use the same Researcher session, deep mode, three OODA loops per stage, external primary sources, and active counter-evidence.
Work only through the Phase Coordinator and stop at every mandatory checkpoint.
Do not change frozen claims, HL, status, iterations.yaml, product files, or the read-only field source; do not push or tag.
Evidence-complete frozen amendments, if any, stop immediately for owner review; ordinary implementation refinements remain within coordinator authority.

Stage complete: YES