mimic-big/tasks/open-questions.md

Open spec questions

Structured questions raised in flight by the team. Each entry is a candidate for team-lead escalation before code touches the area. Resolved questions move to spec-decisions.md (with a D-NNN id) and are deleted from here.

Format:

• Q-NNN — one-line title
  • Where it bites: the F* or §-anchor in the spec
  • What is silent: the precise gap
  • Options: numbered alternatives with tradeoffs
  • Recommended default if no decision: the safest path forward
  • Blocker?: yes / not yet — when does it start blocking implementation

---

Q-001 — regex_extract Jinja2 filter semantics (H26 / D-005)

• Where it bites: F15 cleanup templating + any future F8/F9 evidence templating that references {{ outputs.text }} through a regex.
• What is silent:
  • Multi-match behaviour (return first / all / named groups only?).
  • No-match behaviour (raise / return empty string / return None and let Jinja render it as "None"?).
  • Capture-group selection (whole match vs \1 vs named).
  • Regex engine flavour. D-005 mentions google-re2 (no backrefs, linear time — fits OPSEC) but the spec only says "regex" generically.
• Options:
  1. Strict / first match, named groups required, no-match → raise (loud failure, easy to detect templating bugs early).
  2. First match, fall back to empty string on no-match (silent — matches ATR / Caldera convention).
  3. All matches as list (powerful, but Jinja loops in a cleanup_command are a footgun).
• Recommended default if no decision: option 1 with google-re2 (D-005), raise TemplateError("regex_extract: no match for /<pattern>/") so cleanup templates that drift get caught at template compile time.
• Blocker?: not yet. Becomes blocking when B0.5 implements regex_extract (Jinja sandbox).

Q-002 — output_blob_ref storage layout and quota

• Where it bites: §8 run_step.output_blob_ref, §6 NF-state, H20 ("local disk v1"), F8 evidence (10 MB file cap) and {{ outputs.blob() }} accessor (D-005, 10 MB cap).
• What is silent:
  • Filesystem path layout (/var/lib/mimic/blobs/<engagement_id>/<run_id>/...?).
  • Total quota per engagement / global.
  • Retention vs rotation (kept forever? linked to engagement archival?).
  • Storage object structure: raw bytes? gzip? content-addressed (sha256 dir)?
  • Same file pool as evidence uploads (10 MB cap) or separate?
• Options:
  1. Content-addressed (sha256 hex prefix tree) + gzip + symlink from run_step.output_blob_ref. Deduplication, no quota tracking needed.
  2. Per-engagement directory tree with no compression. Simpler, easier to archive on engagement close, no dedup.
  3. Two pools (blobs/ for C2 outputs, evidence/ for user uploads) so access patterns and quotas stay independent.
• Recommended default if no decision: option 3 with option 1 layout for the blobs/ pool (CAS + gzip), evidence stays plain in evidence/. Hard cap 10 MB per blob, no global quota v1 — disk space monitored at OS level.
• Blocker?: not yet. Becomes blocking when backend implements F5 (run execution) or F8 (evidence upload).

Q-003 — /engagements/:id/hosts/sync merge semantics

• Where it bites: F4 + §9 endpoint /engagements/:id/hosts/sync.
• What is silent:
  • Merge vs replace: do hosts that disappear from C2 get deleted, marked status = "stale", or kept untouched?
  • What if a manually-added host conflicts (same hostname, different c2_session_id)?
  • Source of truth: the C2 session ID, the hostname, the IP, a tuple?
  • Cascading effect: a host referenced by scenario_step.host_id deleted mid-engagement breaks the scenario silently.
• Options:
  1. Merge + mark stale: insert new, update changed, mark missing as status = "stale" (never delete). Conflicts: manual entry wins, C2-synced entry is appended with a suffix and an audit_log entry.
  2. Replace: delete all sync-sourced rows, reinsert from C2. Manual entries kept untouched. Simple but loses history.
  3. Merge by tuple (hostname, c2_session_id) with status tracking, conflicts always raise and require manual resolution UI.
• Recommended default if no decision: option 1. Stale > deleted: a deleted host breaks scenario_step.host_id and the audit trail. Conflict policy: manual wins, C2 entry suffixed and audit-logged.
• Blocker?: not yet. Becomes blocking when backend implements F4 sync endpoint (post-sprint-0, post-PR1).

Q-004 — payload_type → C2 home command mapping (depends on PR2)

• Where it bites: §7 enum payload_type, right column "C2 maison" is fully TBD; F2 import journal C2 home parser; B0.4 C2Connector factory.
• What is silent: entirety of the C2 home mapping table, plus the exact return semantics of HomeConnector.execute_task / get_task_result / cancel_task / execute_cleanup (PR2).
• Options: no in-flight options — this is owned by PR2.
• Recommended default if no decision: keep HomeConnector as a stub that raises NotImplementedError (per B0.4: "no real implementation"). Block any attempt to ship HomeConnector v1 logic until PR2 is closed.
• Blocker?: PR2 is the formal blocker. spec-analyst only needs to make sure no agent quietly invents a mapping table while PR2 is still open.

Q-005 — Stale-host policy after engagement archival

• Where it bites: §8 host.status, engagement lifecycle, F12.
• What is silent: when an engagement is archived, what happens to its hosts? Detach session, freeze status, leave as-is?
• Options:
  1. Set host.status = "archived" cascading from engagement.status.
  2. Keep status untouched, rely on engagement.status upstream.
• Recommended default if no decision: option 2 — engagement state is the single source of truth, hosts inherit by JOIN.
• Blocker?: not yet. Cosmetic for sprint 0, becomes relevant when archival CLI lands.