Open Questions

Purpose: Questions and uncertainties discovered during implementation, with proposed answers and decisions.
Owner: Development Team
Last Updated: 2025-12-22
Status: active

Template

Q: [Question Title]

Context:
[What led to this question? What problem are we trying to solve?]

Files Involved:

path/to/file1.ts
path/to/file2.swift

Options:

Option A: [Description]
- Pros: [list]
- Cons: [list]
Option B: [Description]
- Pros: [list]
- Cons: [list]

Recommendation:
[Which option is recommended and why]

Decision:
[Final decision if made, or "Pending"]

Current Questions

No open questions currently. All architectural decisions have been made.

Closed Questions

Q: What is the authoritative CI entrypoint?

Context:
Need to establish a single source of truth for CI to avoid drift and ensure consistency.

Decision:
./ci/run.sh is canonical. It wraps ./scripts/verify.sh and provides a stable interface for:

CI runners
Release gates
Pre-merge checks
Git hooks (githooks/pre-push)
Makefile targets (make ci)

./scripts/verify.sh is an implementation detail/library function. External systems should call ./ci/run.sh.

Rationale:

Stable interface for automation
Clear separation: entrypoint vs implementation
Easy to add pre/post hooks in the future
Consistent exit codes and output format

Status: ✅ RESOLVED (2025-12-22)

Q: How to enforce core module purity?

Context:
Core module (src/core/) must remain platform-agnostic and portable. Need automated enforcement.

Decision:
Enforce via verify.sh:

Platform import blocking: comprehensive regex detects Node builtins, Capacitor, React
Export validation: Node-based check ensures package.json.exports['./core'] exists
Source checks run before build (works on clean checkouts)
Artifact checks run after build (validates build outputs)