docs: update notification system for shared SQLite + clear T–lead

- Add SQLite Ownership & Concurrency section with WAL mode details
- Add DB Path & Adapter Configuration with shared DB setup
- Clarify T–lead governs prefetch attempts, not arming
- Add TTL-at-fire check callout for stale notification prevention
- Add DB Sharing acceptance criteria (visibility, WAL overlap, version safety)
- Update GLOSSARY.md with shared DB, WAL, and user_version definitions
- Remove plugin-owned DB references in favor of single shared database

Files modified:
- doc/notification-system.md
- doc/GLOSSARY.md

Compliance: Implements shared SQLite architecture with clear T–lead prefetch
semantics and WAL-based concurrency for app/plugin coordination.

.cursor-markdown-rules.md

@@ -181,26 +181,26 @@ Brief description of the document's purpose and scope.
 ### Check Single File
 
 ```bash
-npx markdownlint doc/filename.md
+npx markdownlint docs/filename.md
 ```
 
 ### Check All Documentation
 
 ```bash
-npx markdownlint doc/
+npx markdownlint docs/
 ```
 
 ### Auto-fix Common Issues
 
 ```bash
 # Remove trailing spaces
-sed -i 's/[[:space:]]*$//' doc/filename.md
+sed -i 's/[[:space:]]*$//' docs/filename.md
 
 # Remove multiple blank lines
-sed -i '/^$/N;/^\n$/D' doc/filename.md
+sed -i '/^$/N;/^\n$/D' docs/filename.md
 
 # Add newline at end if missing
-echo "" >> doc/filename.md
+echo "" >> docs/filename.md
 ```
 
 ## Common Patterns

.cursor/rules/README.md

@@ -269,7 +269,7 @@ The workflow system integrates seamlessly with existing development practices:
    your task
 4. **Meta-Rules**: Use workflow-specific meta-rules for specialized tasks
    - **Documentation**: Use `meta_documentation.mdc` for all documentation work
-   - **Getting Started**: See `doc/meta_rule_usage_guide.md` for comprehensive usage instructions
+   - **Getting Started**: See `docs/meta_rule_usage_guide.md` for comprehensive usage instructions
 5. **Cross-References**: All files contain updated cross-references to
    reflect the new structure
 6. **Validation**: All files pass markdown validation and maintain

.cursor/rules/app/timesafari_platforms.mdc

@@ -122,11 +122,11 @@ npm run lint-fix
 
 ## Resources
 
-- **Testing**: `doc/migration-testing/`
+- **Testing**: `docs/migration-testing/`
 
-- **Architecture**: `doc/architecture-decisions.md`
+- **Architecture**: `docs/architecture-decisions.md`
 
-- **Build Context**: `doc/build-modernization-context.md`
+- **Build Context**: `docs/build-modernization-context.md`
 
 ---
 

.cursor/rules/core/base_context.mdc

@@ -21,7 +21,7 @@ alwaysApply: false
 
 ## Purpose
 
-All interactions must *increase the human's competence over time* while
+All interactions must _increase the human's competence over time_ while
 completing the task efficiently. The model may handle menial work and memory
 extension, but must also promote learning, autonomy, and healthy work habits.
 The model should also **encourage human interaction and collaboration** rather
@@ -31,7 +31,7 @@ machine-driven steps.
 
 ## Principles
 
-1. Competence over convenience: finish the task *and* leave the human more
+1. Competence over convenience: finish the task _and_ leave the human more
 
    capable next time.
 
@@ -75,7 +75,7 @@ assumptions if unanswered.
 
 ### timebox_minutes
 
-*integer or null* — When set to a positive integer (e.g., `5`), this acts
+_integer or null_ — When set to a positive integer (e.g., `5`), this acts
 as a **time budget** guiding the model to prioritize delivering the most
 essential parts of the task within that constraint.
 
@@ -91,7 +91,7 @@ Behavior when set:
 
 3. **Signal Skipped Depth** — Omitted details should be listed under
 
-   *Deferred for depth*.
+   _Deferred for depth_.
 
 4. **Order by Value** — Start with blocking or high-value items, then
 
@@ -198,7 +198,7 @@ Default: Doer + short Mentor notes.
 
 ## Self-Check (model, before responding)
 
-- [ ] Task done *and* at least one competence lever included (≤120 words
+- [ ] Task done _and_ at least one competence lever included (≤120 words
   total)
 - [ ] At least one collaboration/discussion hook present
 - [ ] Output follows the **Output Contract** sections

.cursor/rules/core/harbor_pilot_universal.mdc

@@ -53,7 +53,7 @@ evidence-backed steps**.
 - **Verifiable Outputs**: Include expected results, status codes, or
   error messages
 
-- **Cite evidence** for *Works/Doesn't* items (timestamps, filenames,
+- **Cite evidence** for _Works/Doesn't_ items (timestamps, filenames,
   line numbers, IDs/status codes, or logs).
 
 ## Required Sections
@@ -181,8 +181,8 @@ Before publishing, verify:
 
 ---
 
-**Status**: 🚢 ACTIVE — General ruleset extending *Base Context — Human
-Competence First*
+**Status**: 🚢 ACTIVE — General ruleset extending _Base Context — Human
+Competence First_
 
 **Priority**: Critical
 **Estimated Effort**: Ongoing reference

.cursor/rules/core/less_complex.mdc

@@ -12,12 +12,11 @@ language: Match repository languages and conventions
 
 ## Rules
 
-0. **Principle:** just the facts m'am.
 1. **Default to the least complex solution.** Fix the problem directly
    where it occurs; avoid new layers, indirection, or patterns unless
    strictly necessary.
 2. **Keep scope tight.** Implement only what is needed to satisfy the
-   acceptance criteria and tests for *this* issue.
+   acceptance criteria and tests for _this_ issue.
 3. **Avoid speculative abstractions.** Use the **Rule of Three**:
    don't extract helpers/patterns until the third concrete usage proves
    the shape.
@@ -30,7 +29,7 @@ language: Match repository languages and conventions
 7. **Targeted tests only.** Add the smallest set of tests that prove
    the fix and guard against regression; don't rewrite suites.
 8. **Document the "why enough."** Include a one-paragraph note
-   explaining why this minimal solution is sufficient *now*.
+   explaining why this minimal solution is sufficient _now_.
 
 ## Future-Proofing Requires Evidence + Discussion
 

.cursor/rules/development/asset_configuration.mdc

@@ -9,8 +9,8 @@ alwaysApply: false
 **Date**: 2025-08-19
 **Status**: 🎯 **ACTIVE** - Asset management guidelines
 
-*Scope: Assets Only (icons, splashes, image pipelines) — not overall build
-orchestration*
+_Scope: Assets Only (icons, splashes, image pipelines) — not overall build
+orchestration_
 
 ## Intent
 

.cursor/rules/development/development_guide.mdc

@@ -2,8 +2,9 @@
 globs: **/src/**/*
 alwaysApply: false
 ---
-✅ use system date command to timestamp all documentation with accurate date and
+✅ use system date command to timestamp all interactions with accurate date and
   time
+✅ python script files must always have a blank line at their end
 ✅ remove whitespace at the end of lines
 ✅ use npm run lint-fix to check for warnings
 ✅ do not use npm run dev let me handle running and supplying feedback
@@ -21,10 +22,12 @@ alwaysApply: false
 
 - [ ] **Timestamp Usage**: Include accurate timestamps in all interactions
 - [ ] **Code Quality**: Use npm run lint-fix to check for warnings
+- [ ] **File Standards**: Ensure Python files have blank line at end
 - [ ] **Whitespace**: Remove trailing whitespace from all lines
 
 ### After Development
 
 - [ ] **Linting Check**: Run npm run lint-fix to verify code quality
+- [ ] **File Validation**: Confirm Python files end with blank line
 - [ ] **Whitespace Review**: Verify no trailing whitespace remains
 - [ ] **Documentation**: Update relevant documentation with changes

.cursor/rules/development/research_diagnostic.mdc

@@ -122,9 +122,9 @@ Copy/paste and fill:
 
 - `src/...`
 
-- ADR: `doc/adr/xxxx-yy-zz-something.md`
+- ADR: `docs/adr/xxxx-yy-zz-something.md`
 
-- Design: `doc/...`
+- Design: `docs/...`
 
 ## Competence Hooks
 
@@ -230,7 +230,7 @@ Before proposing solutions, trace the actual execution path:
 
   attach during service/feature investigations
 
-- `doc/adr/**` — attach when editing ADRs
+- `docs/adr/**` — attach when editing ADRs
 
 ## Referenced Files
 

.cursor/rules/development/time.mdc

@@ -40,7 +40,7 @@ feature development, issue investigations, ADRs, and documentation**.
 
   `2025-08-17`).
 
-- Avoid ambiguous terms like *recently*, *last month*, or *soon*.
+- Avoid ambiguous terms like _recently_, _last month_, or _soon_.
 
 - For time-based experiments (e.g., A/B tests), always include:
 

.cursor/rules/development/time_implementation.mdc

@@ -19,7 +19,7 @@
 
   - Optionally provide UTC alongside if context requires cross-team clarity.
 
-- When interpreting relative terms like *now*, *today*, *last week*:
+- When interpreting relative terms like _now_, _today_, _last week_:
 
   - Resolve them against the **developer's current time**.
 

.cursor/rules/docs/documentation_references_model_agents.mdc

@@ -0,0 +1,96 @@
+---
+title: Documentation, References, and Model Agent Use
+version: 1.1
+alwaysApply: true
+scope: code, project-plans
+---
+
+# Directive on Documentation, References, and Model Agent Use in Code and Project Plans
+
+To ensure clarity, efficiency, and high-value documentation within code and project plans—and to leverage **model agents** (AI- or automation-based assistants) effectively—contributors must follow these rules:
+
+---
+
+## 1. Documentation and References Must Add Clear Value
+
+- Only include documentation, comments, or reference links when they provide _new, meaningful information_ that assists understanding or decision-making.  
+- Avoid duplicating content already obvious in the codebase, version history, or linked project documents.
+
+---
+
+## 2. Eliminate Redundant or Noisy References
+
+- Remove references that serve no purpose beyond filling space.  
+- Model agents may automatically flag and suggest removal of trivial references (e.g., links to unchanged boilerplate or self-evident context).
+
+---
+
+## 3. Explicit Role of Model Agents
+
+Model agents are **active participants** in documentation quality control. Their tasks include:  
+
+- **Relevance Evaluation**: Automatically analyze references for their substantive contribution before inclusion.  
+- **Redundancy Detection**: Flag duplicate or trivial references across commits, files, or tasks.  
+- **Context Linking**: Suggest appropriate higher-level docs (designs, ADRs, meeting notes) when a code change touches multi-stage or cross-team items.  
+- **Placement Optimization**: Recommend centralization of references (e.g., in plan overviews, ADRs, or merge commit messages) rather than scattered low-value inline references.  
+- **Consistency Monitoring**: Ensure references align with team standards (e.g., ADR template, architecture repo, or external policy documents).  
+
+Contributors must treat agent recommendations as **first-pass reviews** but remain accountable for final human judgment.
+
+---
+
+## 4. Contextual References for Complex Items
+
+- Use **centralized references** for multi-stage features (e.g., architectural docs, research threads).  
+- Keep inline code comments light; push broader context into centralized documents.  
+- Model agents may auto-summarize complex chains of discussion and attach them as a single reference point.
+
+---
+
+## 5. Centralization of Broader Context
+
+- Store overarching context (design docs, proposals, workflows) in accessible, well-indexed places.  
+- Model agents should assist by **generating reference maps** that track where docs are cited across the codebase.
+
+---
+
+## 6. Focused Documentation
+
+- Documentation should explain **why** and **how** decisions are made, not just what was changed.  
+- Model agents can auto-generate first-pass explanations from commit metadata, diffs, and linked issues—but humans must refine them for accuracy and intent.
+
+---
+
+## 7. Review and Accountability
+
+- Reviewers and team leads must reject submissions containing unnecessary or low-quality documentation.  
+- Model agent outputs are aids, not replacements—contributors remain responsible for **final clarity and relevance**.
+
+---
+
+## 8. Continuous Improvement and Agent Feedback Loops
+
+- Encourage iterative development of model agents so their evaluations become more precise over time.  
+- Contributions should include **feedback on agent suggestions** (e.g., accepted, rejected, or corrected) to train better future outputs.  
+- Agents should log patterns of “rejected” suggestions for refinement.  
+
+---
+
+## 9. Workflow Overview (Mermaid Diagram)
+
+```mermaid
+flowchart TD
+    A[Contributor] -->|Writes Code & Draft Docs| B[Model Agent]
+    B -->|Evaluates References| C{Relevant?}
+    C -->|Yes| D[Suggest Placement & Context Links]
+    C -->|No| E[Flag Redundancy / Noise]
+    D --> F[Contributor Refines Docs]
+    E --> F
+    F --> G[Reviewer]
+    G -->|Approves / Requests Revisions| H[Final Documentation]
+    G -->|Feedback on Agent Suggestions| B
+```
+
+---
+
+✅ **Outcome:** By integrating disciplined contributor standards with **model agent augmentation**, the team achieves documentation that is consistently _relevant, concise, centralized, and decision-focused_. AI ensures coverage and noise reduction, while humans ensure precision and judgment.  

.cursor/rules/docs/markdown_templates.mdc

@@ -192,6 +192,7 @@ Summary of key concepts and skills.
 
 Where to apply this knowledge next.
 ```
+
 - [ ] Integration tests
 - [ ] E2E tests
 

.cursor/rules/harbor_pilot_universal.mdc

@@ -1,5 +1,6 @@
 ---
-alwaysApply: false
+alwaysApply: true
+inherits: base_context.mdc
 ---
 ```json
 {
@@ -15,9 +16,10 @@ alwaysApply: false
 
 **Author**: System/Shared  
 **Date**: 2025-08-21 (UTC)  
-**Status**: 🚢 ACTIVE — General ruleset extending *Base Context — Human Competence First*
+**Status**: 🚢 ACTIVE — General ruleset extending _Base Context — Human Competence First_
 
 > **Alignment with Base Context**
+>
 > - **Purpose fit**: Prioritizes human competence and collaboration while delivering reproducible artifacts.  
 > - **Output Contract**: This directive **adds universal constraints** for any technical topic while **inheriting** the Base Context contract sections.  
 > - **Toggles honored**: Uses the same toggle semantics; defaults above can be overridden by the caller.
@@ -25,9 +27,11 @@ alwaysApply: false
 ---
 
 ## Objective
+
 Produce a **developer-grade, reproducible guide** for any technical topic that onboards a competent practitioner **without meta narration** and **with evidence-backed steps**.
 
 ## Scope & Constraints
+
 - **One Markdown document** as the deliverable.
 - Use **absolute dates** in **UTC** (e.g., `2025-08-21T14:22Z`) — avoid “today/yesterday”.
 - Include at least **one diagram** (Mermaid preferred). Choose the most fitting type:
@@ -36,10 +40,11 @@ Produce a **developer-grade, reproducible guide** for any technical topic that o
   - **APIs**: `curl` + one client library (e.g., `httpx` for Python).
   - **CLIs**: literal command blocks and expected output snippets.
   - **Code**: minimal, self-contained samples (language appropriate).
-- Cite **evidence** for *Works/Doesn’t* items (timestamps, filenames, line numbers, IDs/status codes, or logs).
+- Cite **evidence** for _Works/Doesn’t_ items (timestamps, filenames, line numbers, IDs/status codes, or logs).
 - If something is unknown, output `TODO:<missing>` — **never invent**.
 
 ## Required Sections (extends Base Output Contract)
+
 Follow this exact order **after** the Base Contract’s **Objective → Result → Use/Run** headers:
 
 1. **Context & Scope**
@@ -51,9 +56,9 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
 4. **Architecture / Process Overview**
    - Short prose + **one diagram** selected from the list above.
 5. **Interfaces & Contracts (choose one)**
-   - **API-based**: Endpoint table (*Step, Method, Path/URL, Auth, Key Headers/Params, Sample Req/Resp ref*).
-   - **Data/Files**: I/O contract table (*Source, Format, Schema/Columns, Size, Validation rules*).
-   - **Systems/Hardware**: Interfaces table (*Port/Bus, Protocol, Voltage/Timing, Constraints*).
+   - **API-based**: Endpoint table (_Step, Method, Path/URL, Auth, Key Headers/Params, Sample Req/Resp ref_).
+   - **Data/Files**: I/O contract table (_Source, Format, Schema/Columns, Size, Validation rules_).
+   - **Systems/Hardware**: Interfaces table (_Port/Bus, Protocol, Voltage/Timing, Constraints_).
 6. **Repro: End-to-End Procedure**
    - Minimal copy-paste steps with code/commands and **expected outputs**.
 7. **What Works (with Evidence)**
@@ -68,16 +73,19 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
     - Canonical docs, specs, tickets, prior analyses.
 
 > **Competence Hooks (per Base Context; keep lightweight):**
-> - *Why this works* (≤3 bullets) — core invariants or guarantees.  
-> - *Common pitfalls* (≤3 bullets) — the traps we saw in evidence.  
-> - *Next skill unlock* (1 line) — the next capability to implement/learn.  
-> - *Teach-back* (1 line) — prompt the reader to restate the flow/architecture.
+>
+> - _Why this works_ (≤3 bullets) — core invariants or guarantees.  
+> - _Common pitfalls_ (≤3 bullets) — the traps we saw in evidence.  
+> - _Next skill unlock_ (1 line) — the next capability to implement/learn.  
+> - _Teach-back_ (1 line) — prompt the reader to restate the flow/architecture.
 
 > **Collaboration Hooks (per Base Context):**
+>
 > - Name reviewers for **Interfaces & Contracts** and the **diagram**.  
 > - Short **sign-off checklist** before merging/publishing the guide.
 
 ## Do / Don’t (Base-aligned)
+
 - **Do** quantify progress only against a defined scope with acceptance criteria.
 - **Do** include minimal sample payloads/headers or I/O schemas; redact sensitive values.
 - **Do** keep commentary lean; if timeboxed, move depth to **Deferred for depth**.
@@ -85,6 +93,7 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
 - **Don’t** include IDE-specific chatter or internal rules unrelated to the task.
 
 ## Validation Checklist (self-check before returning)
+
 - [ ] All Required Sections present and ordered.  
 - [ ] Diagram compiles (basic Mermaid syntax) and fits the problem.  
 - [ ] If API-based, **Auth** and **Key Headers/Params** are listed for each endpoint.  
@@ -95,6 +104,7 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
 - [ ] Base **Output Contract** sections satisfied (Objective/Result/Use/Run/Competence/Collaboration/Assumptions/References).
 
 ## Universal Template (fill-in)
+
 ```markdown
 # <Title> — Working Notes (As of YYYY-MM-DDTHH:MMZ)
 
@@ -131,37 +141,46 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
 ```
 
 ## Interfaces & Contracts
+
 ### If API-based
+
 | Step | Method | Path/URL | Auth | Key Headers/Params | Sample |
 |---|---|---|---|---|---|
 | <…> | <…> | <…> | <…> | <…> | below |
 
 ### If Data/Files
+
 | Source | Format | Schema/Columns | Size | Validation |
 |---|---|---|---|---|
 | <…> | <…> | <…> | <…> | <…> |
 
 ### If Systems/Hardware
+
 | Interface | Protocol | Timing/Voltage | Constraints | Notes |
 |---|---|---|---|---|
 | <…> | <…> | <…> | <…> | <…> |
 
 ## Repro: End-to-End Procedure
+
 ```bash
 # commands / curl examples (redacted where necessary)
 ```
+
 ```python
 # minimal client library example (language appropriate)
 ```
+
 > Expected output: <snippet/checks>
 
 ## What Works (Evidence)
+
 - ✅ <short statement>  
   - **Time**: <YYYY-MM-DDTHH:MMZ>  
   - **Evidence**: file/line/log or request id/status  
   - **Verify at**: <where>
 
 ## What Doesn’t (Evidence & Hypotheses)
+
 - ❌ <short failure> at `<component/endpoint/file>`  
   - **Time**: <YYYY-MM-DDTHH:MMZ>  
   - **Evidence**: <snippet/id/status>  
@@ -169,38 +188,46 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
   - **Next probe**: <short>
 
 ## Risks, Limits, Assumptions
+
 <bullets: limits, security boundaries, retries/backoff, idempotency, SLOs>
 
 ## Next Steps
+
 | Owner | Task | Exit Criteria | Target Date (UTC) |
 |---|---|---|---|
 | <name> | <action> | <measurable outcome> | <YYYY-MM-DD> |
 
 ## References
+
 <links/titles>
 
 ## Competence Hooks
-- *Why this works*: <≤3 bullets>
-- *Common pitfalls*: <≤3 bullets>
-- *Next skill unlock*: <1 line>
-- *Teach-back*: <1 line>
+
+- _Why this works_: <≤3 bullets>
+- _Common pitfalls_: <≤3 bullets>
+- _Next skill unlock_: <1 line>
+- _Teach-back_: <1 line>
 
 ## Collaboration Hooks
+
 - Reviewers: <names/roles>
 - Sign-off checklist: <≤5 checks>
 
 ## Assumptions & Limits
+
 <bullets>
 
 ## Deferred for depth
+
 <park deeper material here to respect timeboxing>
 ```
 
 ---
 
 **Notes for Implementers:**  
-- Respect Base *Do-Not* (no filler, no invented facts, no censorship).  
+
+- Respect Base _Do-Not_ (no filler, no invented facts, no censorship).  
 - Prefer clarity over completeness when timeboxed; capture unknowns explicitly.
 - Apply historical comment management rules (see `.cursor/rules/historical_comment_management.mdc`)
 - Apply realistic time estimation rules (see `.cursor/rules/realistic_time_estimation.mdc`)
-- Apply Playwright test investigation rules (see `.cursor/rules/playwright_test_investigation.mdc`)
+- Apply Playwright test investigation rules (see `.cursor/rules/playwright_test_investigation.mdc`)

.cursor/rules/meta_bug_diagnosis.mdc

@@ -82,6 +82,7 @@ common investigation pitfalls.
 ### **Safe Diagnosis Commands**
 
 ✅ **Safe to use during diagnosis:**
+
 - `npm run lint-fix` - Syntax and style checking
 - `npm run type-check` - TypeScript validation (if available)
 - `git status` - Version control status
@@ -90,6 +91,7 @@ common investigation pitfalls.
 - `grep_search` - Text pattern searching
 
 ❌ **Never use during diagnosis:**
+
 - `npm run build:web` - Blocks chat
 - `npm run build:electron` - Blocks chat  
 - `npm run build:capacitor` - Blocks chat

.cursor/rules/meta_core_always_on.mdc

@@ -1,6 +1,7 @@
 ---
-alwaysApply: false
+alwaysApply: true
 ---
+
 # Meta-Rule: Core Always-On Rules
 
 **Author**: Matthew Raymer
@@ -35,6 +36,7 @@ that are essential for all AI interactions.
 **This meta-rule enforces current workflow mode constraints for all interactions:**
 
 ### **Current Workflow State**
+
 ```json
 {
   "workflowState": {
@@ -61,26 +63,31 @@ that are essential for all AI interactions.
 ### **Mode-Specific Enforcement**
 
 **Diagnosis Mode (read_only):**
+
 - ❌ **Forbidden**: File modification, code creation, build commands, git commits
 - ✅ **Allowed**: File reading, code analysis, investigation, documentation
 - **Response**: Guide user toward investigation and analysis, not implementation
 
 **Fixing Mode (implementation):**
+
 - ✅ **Allowed**: File modification, code creation, build commands, testing, git commits
 - ❌ **Forbidden**: None (full implementation mode)
 - **Response**: Proceed with implementation and testing
 
 **Planning Mode (design_only):**
+
 - ❌ **Forbidden**: Implementation, coding, building, deployment
 - ✅ **Allowed**: Analysis, design, estimation, documentation, architecture
 - **Response**: Focus on planning and design, not implementation
 
 **Research Mode (investigation):**
+
 - ❌ **Forbidden**: File modification, implementation, deployment
 - ✅ **Allowed**: Investigation, analysis, research, documentation
 - **Response**: Focus on investigation and analysis
 
 **Documentation Mode (writing_only):**
+
 - ❌ **Forbidden**: Implementation, coding, building, deployment
 - ✅ **Allowed**: Writing, editing, formatting, structuring, reviewing
 - **Response**: Focus on documentation creation and improvement
@@ -293,6 +300,9 @@ or context. They form the foundation for all AI assistant behavior.
 **See also**:
 
 - `.cursor/rules/meta_feature_planning.mdc` for workflow-specific rules
+- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation workflows
+- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation
+- `.cursor/rules/meta_feature_implementation.mdc` for feature development
 
 **Status**: Active core always-on meta-rule
 **Priority**: Critical (applies to every prompt)

.cursor/rules/meta_documentation.mdc

@@ -51,6 +51,7 @@ providing technical descriptions.
 ## When to Use
 
 **Use this meta-rule when**:
+
 - Writing new documentation
 - Updating existing documentation
 - Creating technical guides
@@ -107,6 +108,7 @@ providing technical descriptions.
 ### **Document Structure**
 
 **Mandatory Sections**:
+
 - **Overview**: Clear purpose and scope with educational context
 - **Why This Matters**: Business value and user benefit explanation
 - **Core Concepts**: Fundamental understanding before implementation
@@ -116,6 +118,7 @@ providing technical descriptions.
 - **Next Steps**: Where to go from here
 
 **Optional Sections**:
+
 - **Background**: Historical context and evolution
 - **Alternatives**: Other approaches and trade-offs
 - **Advanced Topics**: Deep dive into complex scenarios
@@ -124,6 +127,7 @@ providing technical descriptions.
 ### **Writing Style**
 
 **Educational Approach**:
+
 - **Conversational tone**: Write as if explaining to a colleague
 - **Progressive disclosure**: Start simple, add complexity gradually
 - **Active voice**: "You can do this" not "This can be done"
@@ -131,6 +135,7 @@ providing technical descriptions.
 - **Analogies**: Use familiar concepts to explain complex ideas
 
 **Technical Accuracy**:
+
 - **Precise language**: Use exact technical terms consistently
 - **Code examples**: Working, tested code snippets
 - **Version information**: Specify applicable versions and platforms
@@ -139,6 +144,7 @@ providing technical descriptions.
 ### **Content Quality Standards**
 
 **Educational Value**:
+
 - [ ] **Concept clarity**: Reader understands the fundamental idea
 - [ ] **Context relevance**: Reader knows when to apply the knowledge
 - [ ] **Practical application**: Reader can implement the solution
@@ -146,6 +152,7 @@ providing technical descriptions.
 - [ ] **Next steps**: Reader knows where to continue learning
 
 **Technical Accuracy**:
+
 - [ ] **Fact verification**: All technical details are correct
 - [ ] **Code validation**: Examples compile and run correctly
 - [ ] **Version compatibility**: Platform and version requirements clear
@@ -183,6 +190,7 @@ providing technical descriptions.
 ### **Review Checklist**
 
 **Educational Quality**:
+
 - [ ] **Clear learning objective**: What will the reader learn?
 - [ ] **Appropriate complexity**: Matches target audience knowledge
 - [ ] **Progressive disclosure**: Information builds logically
@@ -190,6 +198,7 @@ providing technical descriptions.
 - [ ] **Common questions**: Anticipates and answers reader questions
 
 **Technical Quality**:
+
 - [ ] **Accuracy**: All technical details verified
 - [ ] **Completeness**: Covers all necessary information
 - [ ] **Consistency**: Terminology and formatting consistent

.cursor/rules/playwright-test-investigation.mdc

@@ -9,26 +9,31 @@ alwaysApply: false
 **Status**: 🎯 **ACTIVE** - Playwright test debugging guidelines
 
 ## Objective
+
 Provide systematic approach for investigating Playwright test failures with focus on UI element conflicts, timing issues, and selector ambiguity.
 
 ## Context & Scope
+
 - **Audience**: Developers debugging Playwright test failures
 - **In scope**: Test failure analysis, selector conflicts, UI state investigation, timing issues
 - **Out of scope**: Test writing best practices, CI/CD configuration
 
 ## Artifacts & Links
+
 - Test results: `test-results/` directory
 - Error context: `error-context.md` files with page snapshots
 - Trace files: `trace.zip` files for failed tests
 - HTML reports: Interactive test reports with screenshots
 
 ## Environment & Preconditions
+
 - OS/Runtime: Linux/Windows/macOS with Node.js
 - Versions: Playwright test framework, browser drivers
 - Services: Local test server (localhost:8080), test data setup
 - Auth mode: None required for test investigation
 
 ## Architecture / Process Overview
+
 Playwright test investigation follows a systematic diagnostic workflow that leverages built-in debugging tools and error context analysis.
 
 ```mermaid
@@ -57,6 +62,7 @@ flowchart TD
 ## Interfaces & Contracts
 
 ### Test Results Structure
+
 | Component | Format | Content | Validation |
 |---|---|---|---|
 | Error Context | Markdown | Page snapshot in YAML | Verify DOM state matches test expectations |
@@ -65,6 +71,7 @@ flowchart TD
 | JSON Results | JSON | Machine-readable results | Parse for automated analysis |
 
 ### Investigation Commands
+
 | Step | Command | Expected Output | Notes |
 |---|---|---|---|
 | Locate failed tests | `find test-results -name "*test-name*"` | Test result directories | Use exact test name patterns |
@@ -74,6 +81,7 @@ flowchart TD
 ## Repro: End-to-End Investigation Procedure
 
 ### 1. Locate Failed Test Results
+
 ```bash
 # Find all results for a specific test
 find test-results -name "*test-name*" -type d
@@ -83,6 +91,7 @@ find test-results -name "error-context.md" | head -5
 ```
 
 ### 2. Analyze Error Context
+
 ```bash
 # Read error context for specific test
 cat test-results/test-name-test-description-browser/error-context.md
@@ -92,6 +101,7 @@ grep -A 10 -B 5 "button.*Yes\|button.*No" test-results/*/error-context.md
 ```
 
 ### 3. Check Trace Files
+
 ```bash
 # List available trace files
 find test-results -name "*.zip" | grep trace
@@ -101,6 +111,7 @@ npx playwright show-trace test-results/test-name/trace.zip
 ```
 
 ### 4. Investigate Selector Issues
+
 ```typescript
 // Check for multiple elements with same text
 await page.locator('button:has-text("Yes")').count(); // Should be 1
@@ -110,6 +121,7 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 ```
 
 ## What Works (Evidence)
+
 - ✅ **Error context files** provide page snapshots showing exact DOM state at failure  
   - **Time**: 2025-08-21T14:22Z  
   - **Evidence**: `test-results/60-new-activity-New-offers-for-another-user-chromium/error-context.md` shows both alerts visible  
@@ -126,6 +138,7 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
   - **Verify at**: Error context markdown files
 
 ## What Doesn't (Evidence & Hypotheses)
+
 - ❌ **Generic selectors** fail with multiple similar elements at `test-playwright/testUtils.ts:161`  
   - **Time**: 2025-08-21T14:22Z  
   - **Evidence**: `button:has-text("Yes")` matches both "Yes" and "Yes, Export Data"  
@@ -139,12 +152,14 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
   - **Next probe**: Implement alert queuing or prevent overlapping alerts
 
 ## Risks, Limits, Assumptions
+
 - **Trace file size**: Large trace files may impact storage and analysis time
 - **Browser compatibility**: Trace viewer requires specific browser support
 - **Test isolation**: Shared state between tests may affect investigation results
 - **Timing sensitivity**: Tests may pass/fail based on system performance
 
 ## Next Steps
+
 | Owner | Task | Exit Criteria | Target Date (UTC) |
 |---|---|---|---|
 | Development Team | Fix test selectors for multiple alerts | All tests pass consistently | 2025-08-22 |
@@ -152,21 +167,25 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 | Development Team | Add test IDs to alert buttons | Unique selectors for all UI elements | 2025-08-28 |
 
 ## References
+
 - [Playwright Trace Viewer Documentation](https://playwright.dev/docs/trace-viewer)
 - [Playwright Test Results](https://playwright.dev/docs/test-reporters)
 - [Test Investigation Workflow](./research_diagnostic.mdc)
 
 ## Competence Hooks
+
 - **Why this works**: Systematic investigation leverages Playwright's built-in debugging tools to identify root causes
 - **Common pitfalls**: Generic selectors fail with multiple similar elements; timing issues create race conditions; alert stacking causes UI conflicts
 - **Next skill unlock**: Implement unique test IDs and handle alert dismissal order in test flows
 - **Teach-back**: "How would you investigate a Playwright test failure using error context, trace files, and page snapshots?"
 
 ## Collaboration Hooks
+
 - **Reviewers**: QA team, test automation engineers
 - **Sign-off checklist**: Error context analyzed, trace files reviewed, root cause identified, fix implemented and tested
 
 ## Assumptions & Limits
+
 - Test results directory structure follows Playwright conventions
 - Trace files are enabled in configuration (`trace: "retain-on-failure"`)
 - Error context files contain valid YAML page snapshots
@@ -178,6 +197,7 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 **Priority**: High  
 **Maintainer**: Development team  
 **Next Review**: 2025-09-21
+
 # Playwright Test Investigation — Harbor Pilot Directive
 
 **Author**: Matthew Raymer  
@@ -185,26 +205,31 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 **Status**: 🎯 **ACTIVE** - Playwright test debugging guidelines
 
 ## Objective
+
 Provide systematic approach for investigating Playwright test failures with focus on UI element conflicts, timing issues, and selector ambiguity.
 
 ## Context & Scope
+
 - **Audience**: Developers debugging Playwright test failures
 - **In scope**: Test failure analysis, selector conflicts, UI state investigation, timing issues
 - **Out of scope**: Test writing best practices, CI/CD configuration
 
 ## Artifacts & Links
+
 - Test results: `test-results/` directory
 - Error context: `error-context.md` files with page snapshots
 - Trace files: `trace.zip` files for failed tests
 - HTML reports: Interactive test reports with screenshots
 
 ## Environment & Preconditions
+
 - OS/Runtime: Linux/Windows/macOS with Node.js
 - Versions: Playwright test framework, browser drivers
 - Services: Local test server (localhost:8080), test data setup
 - Auth mode: None required for test investigation
 
 ## Architecture / Process Overview
+
 Playwright test investigation follows a systematic diagnostic workflow that leverages built-in debugging tools and error context analysis.
 
 ```mermaid
@@ -233,6 +258,7 @@ flowchart TD
 ## Interfaces & Contracts
 
 ### Test Results Structure
+
 | Component | Format | Content | Validation |
 |---|---|---|---|
 | Error Context | Markdown | Page snapshot in YAML | Verify DOM state matches test expectations |
@@ -241,6 +267,7 @@ flowchart TD
 | JSON Results | JSON | Machine-readable results | Parse for automated analysis |
 
 ### Investigation Commands
+
 | Step | Command | Expected Output | Notes |
 |---|---|---|---|
 | Locate failed tests | `find test-results -name "*test-name*"` | Test result directories | Use exact test name patterns |
@@ -250,6 +277,7 @@ flowchart TD
 ## Repro: End-to-End Investigation Procedure
 
 ### 1. Locate Failed Test Results
+
 ```bash
 # Find all results for a specific test
 find test-results -name "*test-name*" -type d
@@ -259,6 +287,7 @@ find test-results -name "error-context.md" | head -5
 ```
 
 ### 2. Analyze Error Context
+
 ```bash
 # Read error context for specific test
 cat test-results/test-name-test-description-browser/error-context.md
@@ -268,6 +297,7 @@ grep -A 10 -B 5 "button.*Yes\|button.*No" test-results/*/error-context.md
 ```
 
 ### 3. Check Trace Files
+
 ```bash
 # List available trace files
 find test-results -name "*.zip" | grep trace
@@ -277,6 +307,7 @@ npx playwright show-trace test-results/test-name/trace.zip
 ```
 
 ### 4. Investigate Selector Issues
+
 ```typescript
 // Check for multiple elements with same text
 await page.locator('button:has-text("Yes")').count(); // Should be 1
@@ -286,6 +317,7 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 ```
 
 ## What Works (Evidence)
+
 - ✅ **Error context files** provide page snapshots showing exact DOM state at failure  
   - **Time**: 2025-08-21T14:22Z  
   - **Evidence**: `test-results/60-new-activity-New-offers-for-another-user-chromium/error-context.md` shows both alerts visible  
@@ -302,6 +334,7 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
   - **Verify at**: Error context markdown files
 
 ## What Doesn't (Evidence & Hypotheses)
+
 - ❌ **Generic selectors** fail with multiple similar elements at `test-playwright/testUtils.ts:161`  
   - **Time**: 2025-08-21T14:22Z  
   - **Evidence**: `button:has-text("Yes")` matches both "Yes" and "Yes, Export Data"  
@@ -315,12 +348,14 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
   - **Next probe**: Implement alert queuing or prevent overlapping alerts
 
 ## Risks, Limits, Assumptions
+
 - **Trace file size**: Large trace files may impact storage and analysis time
 - **Browser compatibility**: Trace viewer requires specific browser support
 - **Test isolation**: Shared state between tests may affect investigation results
 - **Timing sensitivity**: Tests may pass/fail based on system performance
 
 ## Next Steps
+
 | Owner | Task | Exit Criteria | Target Date (UTC) |
 |---|---|---|---|
 | Development Team | Fix test selectors for multiple alerts | All tests pass consistently | 2025-08-22 |
@@ -328,21 +363,25 @@ await page.locator('div[role="alert"]:has-text("Register") button:has-text("Yes"
 | Development Team | Add test IDs to alert buttons | Unique selectors for all UI elements | 2025-08-28 |
 
 ## References
+
 - [Playwright Trace Viewer Documentation](https://playwright.dev/docs/trace-viewer)
 - [Playwright Test Results](https://playwright.dev/docs/test-reporters)
 - [Test Investigation Workflow](./research_diagnostic.mdc)
 
 ## Competence Hooks
+
 - **Why this works**: Systematic investigation leverages Playwright's built-in debugging tools to identify root causes
 - **Common pitfalls**: Generic selectors fail with multiple similar elements; timing issues create race conditions; alert stacking causes UI conflicts
 - **Next skill unlock**: Implement unique test IDs and handle alert dismissal order in test flows
 - **Teach-back**: "How would you investigate a Playwright test failure using error context, trace files, and page snapshots?"
 
 ## Collaboration Hooks
+
 - **Reviewers**: QA team, test automation engineers
 - **Sign-off checklist**: Error context analyzed, trace files reviewed, root cause identified, fix implemented and tested
 
 ## Assumptions & Limits
+
 - Test results directory structure follows Playwright conventions
 - Trace files are enabled in configuration (`trace: "retain-on-failure"`)
 - Error context files contain valid YAML page snapshots

.cursor/rules/workflow/commit_messages.mdc

@@ -73,7 +73,7 @@
 
 ### Avoid
 
-- Vague: *improved, enhanced, better*
+- Vague: _improved, enhanced, better_
 
 - Trivialities: tiny docs, one-liners, pure lint cleanups (separate,
 

.cursor/rules/workflow/version_control.mdc

@@ -5,7 +5,7 @@
 **Status**: 🎯 **ACTIVE** - Version control guidelines
 
 ## Core Principles
-### 0) let the developer control git
+
 ### 1) Version-Control Ownership
 
 - **MUST NOT** run `git add`, `git commit`, or any write action.

.env.development

@@ -6,18 +6,13 @@ VITE_LOG_LEVEL=debug
 # iOS doesn't like spaces in the app title.
 TIME_SAFARI_APP_TITLE="TimeSafari_Dev"
 VITE_APP_SERVER=http://localhost:8080
+# This is the claim ID for actions in the BVC project, with the JWT ID on this environment (not
+
 
-# This is the claim ID for actions in the BVC project, with the JWT ID on the environment
-# test server
 VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZYYPS272F
-# production server
-#VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01GXYPFF7FA03NXKPYY142PY4H
-
 VITE_DEFAULT_ENDORSER_API_SERVER=http://localhost:3000
 # Using shared server by default to ease setup, which works for shared test users.
 VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
 VITE_DEFAULT_PARTNER_API_SERVER=http://localhost:3000
 #VITE_DEFAULT_PUSH_SERVER... can't be set up with localhost domain
-# Using shared test notify API (no local notify server by default).
-VITE_DEFAULT_NOTIFY_API_SERVER=https://test-notify-api.timesafari.app
 VITE_PASSKEYS_ENABLED=true

.env.production

@@ -11,4 +11,3 @@ VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://image-api.timesafari.app
 VITE_DEFAULT_PARTNER_API_SERVER=https://partner-api.endorser.ch
 VITE_DEFAULT_PUSH_SERVER=https://timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://notify-api.timesafari.app

.env.test

@@ -15,5 +15,4 @@ VITE_DEFAULT_ENDORSER_API_SERVER=https://test-api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
 VITE_DEFAULT_PARTNER_API_SERVER=https://test-partner-api.endorser.ch
 VITE_DEFAULT_PUSH_SERVER=https://test.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://test-notify-api.timesafari.app
 VITE_PASSKEYS_ENABLED=true

.gitignore

@@ -16,9 +16,6 @@ myenv
 .env.local
 .env.*.local
 
-# npm configuration with sensitive tokens
-.npmrc
-
 # Log filesopenssl dgst -sha256 -verify public.pem -signature <(echo -n "$signature") "$signing_input"
 npm-debug.log*
 yarn-debug.log*

.husky/_/husky.sh

@@ -1,9 +1,40 @@
-echo "husky - DEPRECATED
-
-Please remove the following two lines from $0:
-
 #!/usr/bin/env sh
-. \"\$(dirname -- \"\$0\")/_/husky.sh\"
+#
+# Husky Helper Script
+# This file is sourced by all Husky hooks
+#
+if [ -z "$husky_skip_init" ]; then
+  debug () {
+    if [ "$HUSKY_DEBUG" = "1" ]; then
+      echo "husky (debug) - $1"
+    fi
+  }
 
-They WILL FAIL in v10.0.0
-"
+  readonly hook_name="$(basename -- "$0")"
+  debug "starting $hook_name..."
+
+  if [ "$HUSKY" = "0" ]; then
+    debug "HUSKY env variable is set to 0, skipping hook"
+    exit 0
+  fi
+
+  if [ -f ~/.huskyrc ]; then
+    debug "sourcing ~/.huskyrc"
+    . ~/.huskyrc
+  fi
+
+  readonly husky_skip_init=1
+  export husky_skip_init
+  sh -e "$0" "$@"
+  exitCode="$?"
+
+  if [ $exitCode != 0 ]; then
+    echo "husky - $hook_name hook exited with code $exitCode (error)"
+  fi
+
+  if [ $exitCode = 127 ]; then
+    echo "husky - command not found in PATH=$PATH"
+  fi
+
+  exit $exitCode
+fi

.husky/pre-commit

@@ -9,10 +9,6 @@ echo "🔍 Running pre-commit hooks..."
 
 # Run lint-fix first
 echo "📝 Running lint-fix..."
-
-# Capture git status before lint-fix to detect changes
-git_status_before=$(git status --porcelain)
-
 npm run lint-fix || {
     echo
     echo "❌ Linting failed. Please fix the issues and try again."
@@ -22,47 +18,16 @@ npm run lint-fix || {
     exit 1
 }
 
-# Check if lint-fix made any changes
-git_status_after=$(git status --porcelain)
-
-if [ "$git_status_before" != "$git_status_after" ]; then
-    echo
-    echo "⚠️  lint-fix made changes to your files!"
-    echo "📋 Changes detected:"
-    git diff --name-only
-    echo
-    echo "❓ What would you like to do?"
-    echo "   [c] Continue commit without the new changes"
-    echo "   [a] Abort commit (recommended - review and stage the changes)"
-    echo
-    printf "Choose [c/a]: "
-    # The `< /dev/tty` is necessary to make read work in git's non-interactive shell
-    read choice < /dev/tty
-    
-    case $choice in
-        [Cc]* )
-            echo "✅ Continuing commit without lint-fix changes..."
-            sleep 3
-            ;;
-        [Aa]* | * )
-            echo "🛑 Commit aborted. Please review the changes made by lint-fix."
-            echo "💡 You can stage the changes with 'git add .' and commit again."
-            exit 1
-            ;;
-    esac
-fi
-
-# Then run Build Architecture Guard
-
-#echo "🏗️  Running Build Architecture Guard..."
-#bash ./scripts/build-arch-guard.sh --staged || {
-#    echo
-#    echo "❌ Build Architecture Guard failed. Please fix the issues and try again."
-#    echo "💡 To bypass this check for emergency commits, use:"
-#    echo "   git commit --no-verify"
-#    echo
-#    exit 1
-#}
+# Build Architecture Guard - DISABLED
+# echo "🏗️  Running Build Architecture Guard..."
+# bash ./scripts/build-arch-guard.sh --staged || {
+#     echo
+#     echo "❌ Build Architecture Guard failed. Please fix the issues and try again."
+#     echo "💡 To bypass this check for emergency commits, use:"
+#     echo "   git commit --no-verify"
+#     echo
+#     exit 1
+# }
 
 echo "✅ All pre-commit checks passed!"
 

.husky/pre-push

@@ -5,23 +5,28 @@
 #
 . "$(dirname -- "$0")/_/husky.sh"
 
-echo "🔍 Running Build Architecture Guard (pre-push)..."
+echo "🔍 Pre-push checks..."
 
-# Get the remote branch we're pushing to
-REMOTE_BRANCH="origin/$(git rev-parse --abbrev-ref HEAD)"
+# Build Architecture Guard - DISABLED
+# echo "🔍 Running Build Architecture Guard (pre-push)..."
+# 
+# # Get the remote branch we're pushing to
+# REMOTE_BRANCH="origin/$(git rev-parse --abbrev-ref HEAD)"
+# 
+# # Check if remote branch exists
+# if git show-ref --verify --quiet "refs/remotes/$REMOTE_BRANCH"; then
+#     RANGE="$REMOTE_BRANCH...HEAD"
+# else
+#     # If remote branch doesn't exist, check last commit
+#     RANGE="HEAD~1..HEAD"
+# fi
+# 
+# bash ./scripts/build-arch-guard.sh --range "$RANGE" || {
+#     echo
+#     echo "💡 To bypass this check for emergency pushes, use:"
+#     echo "   git push --no-verify"
+#     echo
+#     exit 1
+# }
 
-# Check if remote branch exists
-if git show-ref --verify --quiet "refs/remotes/$REMOTE_BRANCH"; then
-    RANGE="$REMOTE_BRANCH...HEAD"
-else
-    # If remote branch doesn't exist, check last commit
-    RANGE="HEAD~1..HEAD"
-fi
-
-#bash ./scripts/build-arch-guard.sh --range "$RANGE" || {
-#    echo
-#    echo "💡 To bypass this check for emergency pushes, use:"
-#    echo "   git push --no-verify"
-#    echo
-#    exit 1
-#}
+echo "✅ Pre-push checks passed!"

.markdownlint.json

@@ -1,27 +1,56 @@
 {
-  "MD013": {
-    "line_length": 80,
-    "code_blocks": false,
-    "tables": false,
-    "headings": false
+  "MD013": false,
+  "MD033": false,
+  "MD041": false,
+  "MD024": {
+    "siblings_only": true
+  },
+  "MD029": {
+    "style": "ordered"
+  },
+  "MD007": {
+    "indent": 2
+  },
+  "MD012": {
+    "maximum": 1
   },
-  "MD012": true,
   "MD022": true,
+  "MD025": true,
+  "MD026": {
+    "punctuation": ".,;:!"
+  },
+  "MD030": {
+    "ul_single": 1,
+    "ol_single": 1,
+    "ul_multi": 1,
+    "ol_multi": 1
+  },
   "MD031": true,
   "MD032": true,
-  "MD047": true,
-  "MD009": true,
-  "MD010": true,
-  "MD004": { "style": "dash" },
-  "MD029": { "style": "ordered" },
-  "MD041": false,
-  "MD025": false,
-  "MD024": false,
+  "MD034": true,
+  "MD035": {
+    "style": "---"
+  },
   "MD036": false,
-  "MD003": false,
-  "MD040": false,
-  "MD055": false,
-  "MD056": false,
-  "MD034": false,
-  "MD023": false
+  "MD037": true,
+  "MD038": true,
+  "MD039": true,
+  "MD040": true,
+  "MD042": true,
+  "MD043": false,
+  "MD044": false,
+  "MD045": true,
+  "MD046": {
+    "style": "fenced"
+  },
+  "MD047": true,
+  "MD048": {
+    "style": "backtick"
+  },
+  "MD049": {
+    "style": "underscore"
+  },
+  "MD050": {
+    "style": "asterisk"
+  }
 }

.npmrc

@@ -0,0 +1 @@
+@jsr:registry=https://npm.jsr.io

BUILDING.md

@@ -93,6 +93,7 @@ The Build Architecture Guard protects your build system by enforcing documentati
 #### Protected File Patterns
 
 The guard monitors these sensitive paths:
+
 - `vite.config.*` - Build configuration
 - `scripts/**` - Build and utility scripts
 - `electron/**` - Desktop application code
@@ -132,6 +133,7 @@ npm run guard:setup
 #### Troubleshooting
 
 If you encounter `mapfile: command not found` errors:
+
 ```bash
 # Ensure script is executable
 chmod +x scripts/build-arch-guard.sh
@@ -164,7 +166,6 @@ cp .env.example .env.development
 # - VITE_DEFAULT_ENDORSER_API_SERVER
 # - VITE_DEFAULT_PARTNER_API_SERVER
 # - VITE_DEFAULT_IMAGE_API_SERVER
-# - VITE_DEFAULT_NOTIFY_API_SERVER
 ```
 
 #### Platform-Specific Development
@@ -176,6 +177,27 @@ cp .env.example .env.development
 
 ### Troubleshooting Quick Fixes
 
+#### Common Issues
+
+```bash
+# Clean and rebuild
+npm run clean:all
+npm install
+npm run build:web:dev
+
+# Reset mobile projects
+npm run clean:ios
+npm run clean:android
+npm run build:ios              # Regenerates iOS project
+npm run build:android          # Regenerates Android project
+
+# Fix Android asset issues
+npm run assets:validate:android # Validates and regenerates missing Android assets
+
+# Check environment
+npm run test:web               # Verifies web setup
+```
+
 #### Platform-Specific Issues
 
 - **iOS**: Ensure Xcode and Command Line Tools are installed
@@ -197,7 +219,7 @@ cp .env.example .env.development
 
 - Node.js 18+ and npm
 - Git
-- For mobile builds: Xcode (macOS) or Android Studio (or Android SDK Command Line Tools for Android emulator only; see [Android Emulator Without Android Studio](#android-emulator-without-android-studio-command-line-only))
+- For mobile builds: Xcode (macOS) or Android Studio
 - For desktop builds: Additional build tools based on your OS
 
 ## Forks
@@ -250,6 +272,7 @@ Start the development server using `npm run build:web:dev` or `npm run build:web
 3. To test the production build locally, use `npm run build:web:serve` (builds then serves)
 
 **Why Use `serve`?**
+
 - **Production Testing**: Test your optimized production build locally before deployment
 - **SPA Routing Validation**: Verify deep linking and navigation work correctly (handles routes like `/discover`, `/account`)
 - **Performance Testing**: Test the minified and optimized build locally
@@ -315,15 +338,18 @@ All web build commands use the `./scripts/build-web.sh` script, which provides:
 The `serve` functionality provides a local HTTP server for testing production builds:
 
 **What It Does:**
+
 1. **Builds** the application using Vite
 2. **Serves** the built files from the `dist/` directory
 3. **Handles SPA Routing** - serves `index.html` for all routes (fixes 404s on `/discover`, `/account`, etc.)
 
 **Server Options:**
+
 - **Primary**: `npx serve -s dist -l 8080` (recommended - full SPA support)
 - **Fallback**: Python HTTP server (limited SPA routing support)
 
 **Use Cases:**
+
 - Testing production builds before deployment
 - Validating SPA routing behavior
 - Performance testing of optimized builds
@@ -345,8 +371,8 @@ current version to test DB migrations.
 - Put the commit hash in the changelog (which will help you remember to bump the
   version in the step later).
 
-- Tag with the new version, 
-[online](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/releases) or 
+- Tag with the new version,
+[online](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/releases) or
 `git tag 1.0.2 && git push origin 1.0.2`.
 
 - For test, build the app:
@@ -365,19 +391,20 @@ rsync -azvu -e "ssh -i ~/.ssh/..." dist ubuntutest@test.timesafari.app:time-safa
 
 (Note: The test BVC_MEETUPS_PROJECT_CLAIM_ID does not resolve as a URL because it's only in the test DB and the prod redirect won't redirect there.)
 
-- For prod, you can do the same with `build:web:prod` instead.
+- For prod, get on the server and run the correct build:
 
-Here are instructions directly on the server, but the build step can stay on "rendering chunks" for a long time and it basically hangs any other access to the server. In fact, last time it was killed: "Failed after 482 seconds (exit code: 137)" Maybe use `nice`?
+... and log onto the server:
 
 - `pkgx +npm sh`
 
-- `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout 1.0.2 && npm install && npm run build:web:prod && cd -`
+- `cd crowd-funder-for-time-pwa && git checkout master && git pull && git checkout
+1.0.2 && npm install && npm run build:web:prod && cd -`
 
 (The plain `npm run build:web:prod` uses the .env.production file.)
 
 - Back up the time-safari/dist folder & deploy: `mv time-safari/dist time-safari-dist-prev-2 && mv crowd-funder-for-time-pwa/dist time-safari/`
 
-Be sure to record the new hash in the changelog. Edit package.json to increment version &
+- Record the new hash in the changelog. Edit package.json to increment version &
 add "-beta", `npm install`, commit, and push. Also record what version is on production.
 
 ## Docker Deployment
@@ -1048,7 +1075,7 @@ npx cap sync electron
 - Package integrity verification
 - Rollback capabilities
 
-For detailed documentation, see [doc/electron-build-patterns.md](doc/electron-build-patterns.md).
+For detailed documentation, see [docs/electron-build-patterns.md](docs/electron-build-patterns.md).
 
 ## Mobile Builds (Capacitor)
 
@@ -1121,40 +1148,37 @@ If you need to build manually or want to understand the individual steps:
 
 - Generate certificates inside XCode.
 - Right-click on App and under Signing & Capabilities set the Team.
-- In the App Developer setup (eg. https://developer.apple.com/account), under Identifiers and/or "Certificates, Identifiers & Profiles"
 
 #### Each Release
 
 ##### 0. First time (or if dependencies change)
 
-- `pkgx +rubygems.org +pod zsh`
+- `pkgx +rubygems.org sh`
 
 - ... and you may have to fix these, especially with pkgx:
 
-```bash
-gem_path=$(which gem)
-shortened_path="${gem_path:h:h}"
-export GEM_HOME=$shortened_path
-export GEM_PATH=$shortened_path
-```
+   ```bash
+   gem_path=$(which gem)
+   shortened_path="${gem_path:h:h}"
+   export GEM_HOME=$shortened_path
+   export GEM_PATH=$shortened_path
+   ```
 
-##### 1. Bump the version in package.json & CHANGELOG.md for `MARKETING_VERSION`, then `grep CURRENT_PROJECT_VERSION ios/App/App.xcodeproj/project.pbxproj` and add 1 for the numbered version here:
+##### 1. Bump the version in package.json, then here
 
-```bash
-cd ios/App && xcrun agvtool new-version 65 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.3.8;/g" App.xcodeproj/project.pbxproj && cd -
-# Unfortunately this edits Info.plist directly.
-#xcrun agvtool new-marketing-version 0.4.5
-```
+   ```bash
+   cd ios/App && xcrun agvtool new-version 40 && perl -p -i -e "s/MARKETING_VERSION = .*;/MARKETING_VERSION = 1.0.7;/g" App.xcodeproj/project.pbxproj && cd -
+   # Unfortunately this edits Info.plist directly.
+   #xcrun agvtool new-marketing-version 0.4.5
+   ```
 
 ##### 2. Build
 
-Here's prod. Also available: test, dev
+  Here's prod. Also available: test, dev
 
-```bash
-npm run build:ios:prod
-```
-
-- The first time, it may complain about a bundler install for "missing gems", and you'll want to run the "install" command it gives you.
+  ```bash
+  npm run build:ios:prod
+  ```
 
 3.1. Use Xcode to build and run on simulator or device.
 
@@ -1167,145 +1191,23 @@ npm run build:ios:prod
 - Choose Product -> Archive
   - This will trigger a build and take time, needing user's "login" keychain
     password (user's login password), repeatedly.
-  - If it fails with `building for 'iOS', but linking in dylib 
+  - If it fails with `building for 'iOS', but linking in dylib
     (.../.pkgx/zlib.net/v1.3.0/lib/libz.1.3.dylib) built for 'macOS'` then run
     XCode outside that terminal (ie. not with `npx cap open ios`).
   - Click Distribute -> App Store Connect
 - In AppStoreConnect, add the build to the distribution. You may have to remove
   the current build with the "-" when you hover over it, then "Add Build" with the
   new build.
-  - May have to go to App Review, click Submission, then hover over the build 
+  - May have to go to App Review, click Submission, then hover over the build
     and click "-".
   - It can take 15 minutes for the build to show up in the list of builds.
   - You'll probably have to "Manage" something about encryption, disallowed in France.
   - Then "Save" and "Add to Review" and "Resubmit to App Review".
-- Eventually it'll be "Ready for Distribution" which means it's live
-- When finished, bump package.json version
+- Eventually it'll be "Ready for Distribution" which means
 
 ### Android Build
 
-Prerequisites: Android Studio with Java SDK installed (or **Android SDK Command Line Tools** only — see [Android Emulator Without Android Studio](#android-emulator-without-android-studio-command-line-only) below).
-
-#### Android Emulator Without Android Studio (Command-Line Only)
-
-You can build and run the app on an Android emulator using only the **Android SDK Command Line Tools** (no Android Studio). The project uses **API 36** (see `android/variables.gradle`: `compileSdkVersion` / `targetSdkVersion`).
-
-##### 1. Environment
-
-Set your SDK location and PATH (e.g. in `~/.zshrc` or `~/.bashrc`):
-
-```bash
-# macOS default SDK location
-export ANDROID_HOME=$HOME/Library/Android/sdk
-# or: export ANDROID_HOME=$HOME/Android/Sdk
-
-export PATH=$PATH:$ANDROID_HOME/emulator
-export PATH=$PATH:$ANDROID_HOME/platform-tools
-export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
-export PATH=$PATH:$ANDROID_HOME/build-tools/34.0.0
-```
-
-Reload your shell (e.g. `source ~/.zshrc`), then verify:
-
-```bash
-adb version
-emulator -version
-avdmanager list
-```
-
-##### 2. Install SDK components
-
-Install platform tools, build tools, platform, and emulator:
-
-```bash
-sdkmanager "platform-tools"
-sdkmanager "build-tools;34.0.0"
-sdkmanager "platforms;android-36"
-sdkmanager "emulator"
-```
-
-##### 3. Install system image and create AVD
-
-**Mac Silicon (Apple M1/M2/M3)** — use **ARM64** for native performance:
-
-```bash
-# System image (API 36 matches the project)
-sdkmanager "system-images;android-36;google_apis;arm64-v8a"
-
-# Create AVD
-avdmanager create avd \
-  --name "TimeSafari_Emulator" \
-  --package "system-images;android-36;google_apis;arm64-v8a" \
-  --device "pixel_7"
-```
-
-**Intel Mac (x86_64):**
-
-```bash
-sdkmanager "system-images;android-36;google_apis;x86_64"
-
-avdmanager create avd \
-  --name "TimeSafari_Emulator" \
-  --package "system-images;android-36;google_apis;x86_64" \
-  --device "pixel_7"
-```
-
-List AVDs: `avdmanager list avd`
-
-##### 4. Start the emulator
-
-```bash
-# Start in background (Mac Silicon or Intel)
-emulator -avd TimeSafari_Emulator -gpu host -no-audio &
-
-# Optional: wait until booted
-adb wait-for-device
-while [ "$(adb shell getprop sys.boot_completed 2>/dev/null)" != "1" ]; do sleep 2; done
-```
-
-If you have limited RAM, use reduced resources:
-
-```bash
-emulator -avd TimeSafari_Emulator -no-audio -memory 2048 -cores 2 -gpu swiftshader_indirect &
-```
-
-Check device: `adb devices`
-
-##### 5. Build the app
-
-From the project root:
-
-```bash
-npm run build:android
-# or: npm run build:android:debug
-```
-
-The debug APK is produced at:  
-`android/app/build/outputs/apk/debug/app-debug.apk`
-
-##### 6. Install and launch on the emulator
-
-With the emulator running:
-
-```bash
-adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
-```
-
-##### One-shot build and run
-
-To build and run in one go (emulator or device must already be running):
-
-```bash
-npm run build:android:debug:run   # debug build, install, launch
-# or
-npm run build:android:test:run   # test env build, install, launch
-```
-
-##### Reference
-
-- Emulator troubleshooting and options: [doc/android-emulator-deployment-guide.md](doc/android-emulator-deployment-guide.md)
-- **Physical device testing**: [doc/android-physical-device-guide.md](doc/android-physical-device-guide.md)
+Prerequisites: Android Studio with Java SDK installed
 
 #### Android Build Commands
 
@@ -1361,11 +1263,13 @@ npm run assets:validate
 ##### What Gets Validated
 
 **Source Assets (Required):**
+
 - `resources/icon.png` - App icon source
 - `resources/splash.png` - Splash screen source  
 - `resources/splash_dark.png` - Dark mode splash source
 
 **Android Resources (Generated):**
+
 - `android/app/src/main/res/drawable/splash.png` - Splash screen drawable
 - `android/app/src/main/res/mipmap-*/ic_launcher.png` - App icons for all densities
 - `android/app/src/main/res/mipmap-*/ic_launcher_round.png` - Round app icons for all densities
@@ -1407,8 +1311,8 @@ The recommended way to build for Android is using the automated build script:
 # Standard build and open Android Studio
 ./scripts/build-android.sh
 
-# Build with specific version numbers -- doesn't change source files
-#./scripts/build-android.sh --version 1.1.3 --build-number 48
+# Build with specific version numbers
+./scripts/build-android.sh --version 1.0.3 --build-number 35
 
 # Build without opening Android Studio (for CI/CD)
 ./scripts/build-android.sh --no-studio
@@ -1419,26 +1323,26 @@ The recommended way to build for Android is using the automated build script:
 
 #### Android Manual Build Process
 
-##### 1. Bump the version in package.json, then update these versions & run:
+##### 1. Bump the version in package.json, then here: android/app/build.gradle
 
-```bash
-perl -p -i -e 's/versionCode .*/versionCode 66/g' android/app/build.gradle
-perl -p -i -e 's/versionName .*/versionName "1.4.1"/g' android/app/build.gradle
-```
+  ```bash
+  perl -p -i -e 's/versionCode .*/versionCode 40/g' android/app/build.gradle
+  perl -p -i -e 's/versionName .*/versionName "1.0.7"/g' android/app/build.gradle
+  ```
 
 ##### 2. Build
 
   Here's prod. Also available: test, dev
 
-```bash
-npm run build:android:prod
-```
+  ```bash
+  npm run build:android:prod
+  ```
 
 ##### 3. Open the project in Android Studio
 
-```bash
-npx cap open android
-```
+   ```bash
+   npx cap open android
+   ```
 
 ##### 4. Use Android Studio to build and run on emulator or device
 
@@ -1483,8 +1387,6 @@ At play.google.com/console:
 - Note that if you add testers, you have to go to "Publishing Overview" and send
   those changes or your (closed) testers won't see it.
 
-- When finished, bump package.json version
-
 ### Capacitor Operations
 
 ```bash
@@ -1651,7 +1553,6 @@ The build system supports multiple environment file patterns for different scena
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
 VITE_DEFAULT_PARTNER_API_SERVER=https://partner-api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://notify-api.timesafari.app
 
 # Platform Configuration
 VITE_PLATFORM=web|electron|capacitor
@@ -1671,7 +1572,6 @@ VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZY
 VITE_DEFAULT_ENDORSER_API_SERVER=http://localhost:3000
 VITE_DEFAULT_PARTNER_API_SERVER=http://localhost:3000
 VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://test-notify-api.timesafari.app
 VITE_APP_SERVER=http://localhost:8080
 ```
 
@@ -1682,7 +1582,6 @@ VITE_APP_SERVER=http://localhost:8080
 VITE_DEFAULT_ENDORSER_API_SERVER=https://test-api.endorser.ch
 VITE_DEFAULT_PARTNER_API_SERVER=https://test-partner-api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://test-notify-api.timesafari.app
 VITE_APP_SERVER=https://test.timesafari.app
 ```
 
@@ -1693,7 +1592,6 @@ VITE_APP_SERVER=https://test.timesafari.app
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
 VITE_DEFAULT_PARTNER_API_SERVER=https://partner-api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://notify-api.timesafari.app
 VITE_APP_SERVER=https://timesafari.app
 ```
 
@@ -1816,13 +1714,11 @@ npm run build:android:assets
 
 ## Additional Resources
 
-- [Electron Build Patterns](doc/electron-build-patterns.md)
-- [iOS Build Scripts](doc/ios-build-scripts.md)
-- [Android Build Scripts](doc/android-build-scripts.md)
-- [Android Physical Device Guide](doc/android-physical-device-guide.md)
-- [Android Emulator Deployment Guide](doc/android-emulator-deployment-guide.md)
-- [Web Build Scripts](doc/web-build-scripts.md)
-- [Build Troubleshooting](doc/build-troubleshooting.md)
+- [Electron Build Patterns](docs/electron-build-patterns.md)
+- [iOS Build Scripts](docs/ios-build-scripts.md)
+- [Android Build Scripts](docs/android-build-scripts.md)
+- [Web Build Scripts](docs/web-build-scripts.md)
+- [Build Troubleshooting](docs/build-troubleshooting.md)
 
 ---
 
@@ -1951,7 +1847,6 @@ The build system supports multiple environment file patterns:
 VITE_DEFAULT_ENDORSER_API_SERVER=https://api.endorser.ch
 VITE_DEFAULT_PARTNER_API_SERVER=https://partner-api.endorser.ch
 VITE_DEFAULT_IMAGE_API_SERVER=https://image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://notify-api.timesafari.app
 
 # Platform Configuration
 VITE_PLATFORM=web|electron|capacitor
@@ -2446,7 +2341,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
     resolve: {
       alias: {
         '@': path.resolve(__dirname, 'src'),
-        'nostr-tools': path.resolve(__dirname, 'node_modules/nostr-tools'),
+        '@nostr/tools': path.resolve(__dirname, 'node_modules/@nostr/tools'),
         'path': path.resolve(__dirname, './src/utils/node-modules/path.js'),
         'fs': path.resolve(__dirname, './src/utils/node-modules/fs.js'),
         'crypto': path.resolve(__dirname, './src/utils/node-modules/crypto.js'),
@@ -2455,7 +2350,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
     },
     optimizeDeps: {
       include: [
-        'nostr-tools',
+        '@nostr/tools',
         '@jlongster/sql.js',
         'absurd-sql',
         // ... additional dependencies
@@ -2480,7 +2375,7 @@ export async function createBuildConfig(platform: string): Promise<UserConfig> {
 **Path Aliases**:
 
 - `@`: Points to `src/` directory
-- `nostr-tools`: Nostr tools library
+- `@nostr/tools`: Nostr tools library
 - `path`, `fs`, `crypto`: Node.js polyfills for browser
 
 ### B.2 vite.config.web.mts
@@ -2620,7 +2515,7 @@ export default defineConfig(async () => {
         output: {
           manualChunks: {
             vendor: ["vue", "vue-router", "@vueuse/core"],
-            crypto: ["nostr-tools", "crypto-js"],
+            crypto: ["@nostr/tools", "crypto-js"],
             ui: ["@fortawesome/vue-fontawesome"]
           }
         }
@@ -2819,6 +2714,7 @@ configuration files in the repository.
 ### 2025-08-21 - Cursor Rules Refactoring and Build System Updates
 
 #### Package Dependencies Updated
+
 - **Added**: `markdownlint-cli2` v0.18.1 - Modern markdown linting with improved performance
 - **Added**: `@commitlint/cli` v18.6.1 - Conventional commit message validation
 - **Added**: `@commitlint/config-conventional` v18.6.2 - Conventional commit standards
@@ -2826,28 +2722,33 @@ configuration files in the repository.
 - **Updated**: `lint-staged` v15.2.2 - Pre-commit linting automation
 
 #### Build Script Improvements
+
 - **Markdown Linting**: Replaced custom markdown scripts with `markdownlint-cli2`
   - **Before**: `./scripts/fix-markdown.sh` and `./scripts/validate-markdown.sh`
   - **After**: `markdownlint-cli2 --fix` and `markdownlint-cli2`
   - **Benefits**: Faster execution, better error reporting, modern markdown standards
 
 #### Lint-Staged Configuration Enhanced
+
 - **Added**: Markdown file linting to pre-commit hooks
   - **Pattern**: `*.{md,markdown,mdc}` files now automatically formatted
   - **Command**: `markdownlint-cli2 --fix` runs before each commit
   - **Coverage**: All markdown files including `.mdc` cursor rules
 
 #### Commit Message Standards
+
 - **Added**: Conventional commit validation via commitlint
 - **Configuration**: Extends `@commitlint/config-conventional`
 - **Enforcement**: Ensures consistent commit message format across the project
 
 #### Node.js Version Requirements
+
 - **Updated**: Minimum Node.js version requirements for new dependencies
 - **markdownlint-cli2**: Requires Node.js >=20
 - **Various utilities**: Require Node.js >=18 for modern ES features
 
 #### Build Process Impact
+
 - **No Breaking Changes**: All existing build commands continue to work
 - **Improved Quality**: Better markdown formatting and commit message standards
 - **Enhanced Automation**: More comprehensive pre-commit validation
@@ -2858,6 +2759,7 @@ configuration files in the repository.
 ### 2025-08-21 - Commitlint Configuration Refinement
 
 #### Commit Message Validation Improvements
+
 - **Modified**: Commitlint configuration moved from `package.json` to dedicated `commitlint.config.js`
 - **Enhanced**: Strict validation rules downgraded from errors to warnings
   - **Before**: `subject-case` and `subject-full-stop` rules caused red error messages
@@ -2865,16 +2767,18 @@ configuration files in the repository.
 - **Benefit**: Eliminates confusing red error messages while maintaining commit quality guidance
 
 #### Configuration Structure
+
 - **File**: `commitlint.config.js` - Dedicated commitlint configuration
 - **Extends**: `@commitlint/config-conventional` - Standard conventional commit rules
-- **Custom Rules**: 
+- **Custom Rules**:
   - `subject-case: [1, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']]`
   - `subject-full-stop: [1, 'never', '.']`
-- **Levels**: 
+- **Levels**:
   - `0` = Disabled, `1` = Warning, `2` = Error
   - Current: Problematic rules set to warning level (1)
 
 #### User Experience Impact
+
 - **Before**: Red error messages on every push with strict commit rules
 - **After**: Yellow warning messages that provide guidance without disruption
 - **Workflow**: Commits and pushes continue to work while maintaining quality standards
@@ -2885,6 +2789,7 @@ configuration files in the repository.
 ### 2025-08-26 - Capacitor Plugin Additions
 
 #### New Capacitor Plugins Added
+
 - **Added**: `@capacitor/clipboard` v6.0.2 - Clipboard functionality for mobile platforms
   - **Purpose**: Enable copy/paste operations on mobile devices
   - **Platforms**: iOS and Android
@@ -2898,23 +2803,27 @@ configuration files in the repository.
   - **Integration**: Automatically included in mobile builds
 
 #### Android Build System Updates
+
 - **Modified**: `android/capacitor.settings.gradle` - Added new plugin project includes
   - **Added**: `:capacitor-clipboard` project directory mapping
   - **Added**: `:capacitor-status-bar` project directory mapping
   - **Impact**: New plugins now properly integrated into Android build process
 
 #### Package Dependencies
+
 - **Updated**: `package.json` - Added new Capacitor plugin dependencies
 - **Updated**: `package-lock.json` - Locked dependency versions for consistency
 - **Version**: All new plugins use Capacitor 6.x compatible versions
 
 #### Build Process Impact
+
 - **No Breaking Changes**: Existing build commands continue to work unchanged
 - **Enhanced Mobile Features**: New clipboard and status bar capabilities available
 - **Automatic Integration**: Plugins automatically included in mobile builds
 - **Platform Support**: Both iOS and Android builds now include new functionality
 
 #### Testing Requirements
+
 - **Mobile Builds**: Verify new plugins integrate correctly in iOS and Android builds
 - **Functionality**: Test clipboard operations and status bar management on devices
 - **Fallback**: Ensure graceful degradation when plugins are unavailable

CHANGELOG.md

@@ -5,84 +5,6 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-
-## [1.3.8] - 2026
-### Added
-- Device wake-up for notifications
-
-
-## [1.3.7]
-### Added
-- Attendee exclusion and do-not-pair groups for meeting matching.
-### Fixed
-- Contact deep-links clicked or pasted act consistenly
-
-
-## [1.3.5] - 2026.02.22
-### Fixed
-- SQL error on startup (contact_labels -> contacts foreign key)
-### Added
-- Ability to toggle embeddings on list of contacts
-
-
-## [1.3.3] - 2026.02.17
-### Added
-- People can be marked as vector-embeddings users.
-- People can be matched during a meeting.
-### Fixed
-- Problem hiding new contacts in feed
-
-
-## [1.1.6] - 2026.01.21
-### Added
-- Labels on contacts
-- Ability to switch giver & recipient on the gift-details page
-### Changed
-- Invitations now must be explicitly accepted.
-### Fixed
-- Show all starred projects.
-- Incorrect contacts as "most recent" on gift-details page
-
-
-## [1.1.5] - 2025.12.28
-### Fixed
-- Incorrect prompts in give-dialog on a project or offer
-
-
-## [1.1.4] - 2025.12.18
-### Fixed
-- Contact notes & contact methods preserved in export
-### Added
-- This is a target for sharing
-- Switch to a project or person in give-dialog pop-up
-- Starred projects onto project-choice in give-dialog pop-up
-### Changed
-- Front page: 1 green "Thank" button
-
-
-## [1.1.3] - 2025.11.19
-### Changed
-- Project selection in dialogs now reaches out to server when filtering
-- Project selection during onboarding meeting is a search (not an input box)
-- Improve the switching of agent when agent edits a project
-### Fixed
-- Reassignment of "you" as recipient when changing giver project
-- Bad counts for project-change notification on front page
-
-
-## [1.1.2] - 2025.11.06
-### Fixed
-- Bad page when user follows prompt to backup seed
-
-
-## [1.1.1] - 2025.11.03
-
-### Added
-- Meeting onboarding via prompts
-- Emojis on gift feed
-- Starred projects with notification
-
-
 ## [1.0.7] - 2025.08.18
 
 ### Fixed

CODE_QUALITY_DEEP_ANALYSIS.md

@@ -1,852 +0,0 @@
-# TimeSafari Code Quality: Comprehensive Deep Analysis
-
-**Author**: Matthew Raymer  
-**Date**: Tue Sep 16 05:22:10 AM UTC 2025  
-**Status**: 🎯 **COMPREHENSIVE ANALYSIS** - Complete code quality assessment with actionable recommendations
-
-## Executive Summary
-
-The TimeSafari codebase demonstrates **exceptional code quality** with mature patterns, minimal technical debt, and excellent separation of concerns. This comprehensive analysis covers **291 source files** totaling **104,527 lines** of code, including detailed examination of **94 Vue components and views**.
-
-**Key Quality Metrics:**
-- **Technical Debt**: Extremely low (6 TODO/FIXME comments across entire codebase)
-- **Database Migration**: 99.5% complete (1 remaining legacy import)
-- **File Complexity**: High variance (largest file: 2,215 lines)
-- **Type Safety**: Mixed patterns (41 "as any" assertions in Vue files, 62 total)
-- **Error Handling**: Comprehensive (367 catch blocks with good coverage)
-- **Architecture**: Consistent Vue 3 Composition API with TypeScript
-
-## Vue Components & Views Analysis (94 Files)
-
-### Component Analysis (40 Components)
-
-#### Component Size Distribution
-```
-Large Components (>500 lines): 5 components (12.5%)
-├── ImageMethodDialog.vue (947 lines) 🔴 CRITICAL
-├── GiftedDialog.vue (670 lines) ⚠️ HIGH PRIORITY  
-├── PhotoDialog.vue (669 lines) ⚠️ HIGH PRIORITY
-├── PushNotificationPermission.vue (660 lines) ⚠️ HIGH PRIORITY
-└── MeetingMembersList.vue (550 lines) ⚠️ MODERATE PRIORITY
-
-Medium Components (200-500 lines): 12 components (30%)
-├── GiftDetailsStep.vue (450 lines)
-├── EntityGrid.vue (348 lines)
-├── ActivityListItem.vue (334 lines)
-├── OfferDialog.vue (327 lines)
-├── OnboardingDialog.vue (314 lines)
-├── EntitySelectionStep.vue (313 lines)
-├── GiftedPrompts.vue (293 lines)
-├── ChoiceButtonDialog.vue (250 lines)
-├── DataExportSection.vue (251 lines)
-├── AmountInput.vue (224 lines)
-├── HiddenDidDialog.vue (220 lines)
-└── FeedFilters.vue (218 lines)
-
-Small Components (<200 lines): 23 components (57.5%)
-├── ContactListItem.vue (217 lines)
-├── EntitySummaryButton.vue (202 lines)
-├── IdentitySection.vue (186 lines)
-├── ContactInputForm.vue (173 lines)
-├── SpecialEntityCard.vue (156 lines)
-├── RegistrationNotice.vue (154 lines)
-├── ContactNameDialog.vue (154 lines)
-├── PersonCard.vue (153 lines)
-├── UserNameDialog.vue (147 lines)
-├── InfiniteScroll.vue (132 lines)
-├── LocationSearchSection.vue (124 lines)
-├── UsageLimitsSection.vue (123 lines)
-├── QuickNav.vue (118 lines)
-├── ProjectCard.vue (104 lines)
-├── ContactListHeader.vue (101 lines)
-├── TopMessage.vue (98 lines)
-├── InviteDialog.vue (95 lines)
-├── ImageViewer.vue (94 lines)
-├── EntityIcon.vue (86 lines)
-├── ShowAllCard.vue (66 lines)
-├── ContactBulkActions.vue (53 lines)
-├── ProjectIcon.vue (47 lines)
-└── LargeIdenticonModal.vue (44 lines)
-```
-
-#### Critical Component Analysis
-
-**1. `ImageMethodDialog.vue` (947 lines) 🔴 CRITICAL REFACTORING NEEDED**
-
-**Issues Identified:**
-- **Excessive Single Responsibility**: Handles camera preview, file upload, URL input, cropping, diagnostics, and error handling
-- **Complex State Management**: 20+ reactive properties with interdependencies
-- **Mixed Concerns**: Camera API, file handling, UI state, and business logic intertwined
-- **Template Complexity**: ~300 lines of template with deeply nested conditions
-
-**Refactoring Strategy:**
-```typescript
-// Current monolithic structure
-ImageMethodDialog.vue (947 lines) {
-  CameraPreview: ~200 lines
-  FileUpload: ~150 lines  
-  URLInput: ~100 lines
-  CroppingInterface: ~200 lines
-  DiagnosticsPanel: ~150 lines
-  ErrorHandling: ~100 lines
-  StateManagement: ~47 lines
-}
-
-// Proposed component decomposition
-ImageMethodDialog.vue (coordinator, ~200 lines)
-├── CameraPreviewComponent.vue (~250 lines)
-├── FileUploadComponent.vue (~150 lines)
-├── URLInputComponent.vue (~100 lines)
-├── ImageCropperComponent.vue (~200 lines)
-├── DiagnosticsPanelComponent.vue (~150 lines)
-└── ImageUploadErrorHandler.vue (~100 lines)
-```
-
-**2. `GiftedDialog.vue` (670 lines) ⚠️ HIGH PRIORITY**
-
-**Assessment**: **GOOD** - Already partially refactored with step components extracted.
-
-**3. `PhotoDialog.vue` (669 lines) ⚠️ HIGH PRIORITY**
-
-**Issues**: Similar to ImageMethodDialog with significant code duplication.
-
-**4. `PushNotificationPermission.vue` (660 lines) ⚠️ HIGH PRIORITY**
-
-**Issues**: Complex permission logic with platform-specific code mixed together.
-
-### View Analysis (54 Views)
-
-#### View Size Distribution
-```
-Large Views (>1000 lines): 9 views (16.7%)
-├── AccountViewView.vue (2,215 lines) 🔴 CRITICAL
-├── HomeView.vue (1,852 lines) ⚠️ HIGH PRIORITY
-├── ProjectViewView.vue (1,479 lines) ⚠️ HIGH PRIORITY
-├── DatabaseMigration.vue (1,438 lines) ⚠️ HIGH PRIORITY
-├── ContactsView.vue (1,382 lines) ⚠️ HIGH PRIORITY
-├── TestView.vue (1,259 lines) ⚠️ MODERATE PRIORITY
-├── ClaimView.vue (1,225 lines) ⚠️ MODERATE PRIORITY
-├── NewEditProjectView.vue (957 lines) ⚠️ MODERATE PRIORITY
-└── ContactQRScanShowView.vue (929 lines) ⚠️ MODERATE PRIORITY
-
-Medium Views (500-1000 lines): 8 views (14.8%)
-├── ConfirmGiftView.vue (898 lines)
-├── DiscoverView.vue (888 lines)
-├── DIDView.vue (848 lines)
-├── GiftedDetailsView.vue (840 lines)
-├── OfferDetailsView.vue (781 lines)
-├── HelpView.vue (780 lines)
-├── ProjectsView.vue (742 lines)
-└── ContactQRScanFullView.vue (701 lines)
-
-Small Views (<500 lines): 37 views (68.5%)
-├── OnboardMeetingSetupView.vue (687 lines)
-├── ContactImportView.vue (568 lines)
-├── HelpNotificationsView.vue (566 lines)
-├── OnboardMeetingListView.vue (507 lines)
-├── InviteOneView.vue (475 lines)
-├── QuickActionBvcEndView.vue (442 lines)
-├── ContactAmountsView.vue (416 lines)
-├── SearchAreaView.vue (384 lines)
-├── SharedPhotoView.vue (379 lines)
-├── ContactGiftingView.vue (373 lines)
-├── ContactEditView.vue (345 lines)
-├── IdentitySwitcherView.vue (324 lines)
-├── UserProfileView.vue (323 lines)
-├── NewActivityView.vue (323 lines)
-├── QuickActionBvcBeginView.vue (303 lines)
-├── SeedBackupView.vue (292 lines)
-├── InviteOneAcceptView.vue (292 lines)
-├── ClaimCertificateView.vue (279 lines)
-├── StartView.vue (271 lines)
-├── ImportAccountView.vue (265 lines)
-├── ClaimAddRawView.vue (249 lines)
-├── OnboardMeetingMembersView.vue (247 lines)
-├── DeepLinkErrorView.vue (239 lines)
-├── ClaimReportCertificateView.vue (236 lines)
-├── DeepLinkRedirectView.vue (219 lines)
-├── ImportDerivedAccountView.vue (207 lines)
-├── ShareMyContactInfoView.vue (196 lines)
-├── RecentOffersToUserProjectsView.vue (176 lines)
-├── RecentOffersToUserView.vue (166 lines)
-├── NewEditAccountView.vue (142 lines)
-├── StatisticsView.vue (133 lines)
-├── HelpOnboardingView.vue (118 lines)
-├── LogView.vue (104 lines)
-├── NewIdentifierView.vue (97 lines)
-├── HelpNotificationTypesView.vue (73 lines)
-├── ConfirmContactView.vue (57 lines)
-└── QuickActionBvcView.vue (54 lines)
-```
-
-#### Critical View Analysis
-
-**1. `AccountViewView.vue` (2,215 lines) 🔴 CRITICAL REFACTORING NEEDED**
-
-**Issues Identified:**
-- **Monolithic Architecture**: Handles 7 distinct concerns in single file
-- **Template Complexity**: ~750 lines of template with deeply nested conditions
-- **Method Proliferation**: 50+ methods handling disparate concerns
-- **State Management**: 25+ reactive properties without clear organization
-
-**Refactoring Strategy:**
-```typescript
-// Current monolithic structure
-AccountViewView.vue (2,215 lines) {
-  ProfileSection: ~400 lines
-  SettingsSection: ~300 lines  
-  NotificationSection: ~200 lines
-  ServerConfigSection: ~250 lines
-  ExportImportSection: ~300 lines
-  LimitsSection: ~150 lines
-  MapSection: ~200 lines
-  StateManagement: ~415 lines
-}
-
-// Proposed component extraction
-AccountViewView.vue (coordinator, ~400 lines)
-├── ProfileManagementSection.vue (~300 lines)
-├── ServerConfigurationSection.vue (~250 lines)
-├── NotificationSettingsSection.vue (~200 lines)
-├── DataExportImportSection.vue (~300 lines)
-├── UsageLimitsDisplay.vue (~150 lines)
-├── LocationProfileSection.vue (~200 lines)
-└── AccountViewStateManager.ts (~200 lines)
-```
-
-**2. `HomeView.vue` (1,852 lines) ⚠️ HIGH PRIORITY**
-
-**Issues Identified:**
-- **Multiple Concerns**: Activity feed, projects, contacts, notifications in one file
-- **Complex State Management**: 20+ reactive properties with interdependencies
-- **Mixed Lifecycle Logic**: Mount, update, and destroy logic intertwined
-
-**3. `ProjectViewView.vue` (1,479 lines) ⚠️ HIGH PRIORITY**
-
-**Issues Identified:**
-- **Project Management Complexity**: Handles project details, members, offers, and activities
-- **Mixed Concerns**: Project data, member management, and activity feed in single view
-
-### Vue Component Quality Patterns
-
-#### Excellent Patterns Found:
-
-**1. EntityIcon.vue (86 lines) ✅ EXCELLENT**
-```typescript
-// Clean, focused responsibility
-@Component({ name: "EntityIcon" })
-export default class EntityIcon extends Vue {
-  @Prop() contact?: Contact;
-  @Prop({ default: "" }) entityId!: string;
-  @Prop({ default: 0 }) iconSize!: number;
-  
-  generateIcon(): string {
-    // Clear priority order: profile image → avatar → fallback
-    const imageUrl = this.contact?.profileImageUrl || this.profileImageUrl;
-    if (imageUrl) return `<img src="${imageUrl}" ... />`;
-    
-    const identifier = this.contact?.did || this.entityId;
-    if (!identifier) return `<img src="${blankSquareSvg}" ... />`;
-    
-    return createAvatar(avataaars, { seed: identifier, size: this.iconSize }).toString();
-  }
-}
-```
-
-**2. QuickNav.vue (118 lines) ✅ EXCELLENT**
-```typescript
-// Simple, focused navigation component
-@Component({ name: "QuickNav" })
-export default class QuickNav extends Vue {
-  @Prop selected = "";
-  
-  // Clean template with consistent patterns
-  // Proper accessibility attributes
-  // Responsive design with safe area handling
-}
-```
-
-**3. Small Focused Views ✅ EXCELLENT**
-```typescript
-// QuickActionBvcView.vue (54 lines) - Perfect size
-// ConfirmContactView.vue (57 lines) - Focused responsibility
-// HelpNotificationTypesView.vue (73 lines) - Clear purpose
-// LogView.vue (104 lines) - Simple utility view
-```
-
-#### Problematic Patterns Found:
-
-**1. Excessive Props in Dialog Components**
-```typescript
-// GiftedDialog.vue - Too many props
-@Prop() fromProjectId = "";
-@Prop() toProjectId = "";
-@Prop() isFromProjectView = false;
-@Prop() hideShowAll = false;
-@Prop({ default: "person" }) giverEntityType = "person";
-@Prop({ default: "person" }) recipientEntityType = "person";
-// ... 10+ more props
-```
-
-**2. Complex State Machines**
-```typescript
-// ImageMethodDialog.vue - Complex state management
-cameraState: "off" | "initializing" | "active" | "error" | "retrying" | "stopped" = "off";
-showCameraPreview = false;
-isRetrying = false;
-showDiagnostics = false;
-// ... 15+ more state properties
-```
-
-**3. Excessive Reactive Properties**
-```typescript
-// AccountViewView.vue - Too many reactive properties
-downloadUrl: string = "";
-loadingLimits: boolean = false;
-loadingProfile: boolean = true;
-showAdvanced: boolean = false;
-showB64Copy: boolean = false;
-showContactGives: boolean = false;
-showDidCopy: boolean = false;
-showDerCopy: boolean = false;
-showGeneralAdvanced: boolean = false;
-showLargeIdenticonId?: string;
-showLargeIdenticonUrl?: string;
-showPubCopy: boolean = false;
-showShortcutBvc: boolean = false;
-warnIfProdServer: boolean = false;
-warnIfTestServer: boolean = false;
-zoom: number = 2;
-isMapReady: boolean = false;
-// ... 10+ more properties
-```
-
-## File Size and Complexity Analysis (All Files)
-
-### Problematic Large Files
-
-#### 1. `AccountViewView.vue` (2,215 lines) 🔴 **CRITICAL**
-**Issues Identified:**
-- **Excessive Single File Responsibility**: Handles profile, settings, notifications, server configuration, export/import, limits checking
-- **Template Complexity**: ~750 lines of template with deeply nested conditions
-- **Method Proliferation**: 50+ methods handling disparate concerns
-- **State Management**: 25+ reactive properties without clear organization
-
-#### 2. `PlatformServiceMixin.ts` (2,091 lines) ⚠️ **HIGH PRIORITY**
-**Issues Identified:**
-- **God Object Pattern**: Single file handling 80+ methods across multiple concerns
-- **Mixed Abstraction Levels**: Low-level SQL utilities mixed with high-level business logic
-- **Method Length Variance**: Some methods 100+ lines, others single-line wrappers
-
-**Refactoring Strategy:**
-```typescript
-// Current monolithic mixin
-PlatformServiceMixin.ts (2,091 lines)
-
-// Proposed separation of concerns
-├── CoreDatabaseMixin.ts          // $db, $exec, $query, $first (200 lines)
-├── SettingsManagementMixin.ts    // $settings, $saveSettings (400 lines)
-├── ContactManagementMixin.ts     // $contacts, $insertContact (300 lines)
-├── EntityOperationsMixin.ts      // $insertEntity, $updateEntity (400 lines)
-├── CachingMixin.ts              // Cache management (150 lines)
-├── ActiveIdentityMixin.ts       // Active DID management (200 lines)
-├── UtilityMixin.ts              // Mapping, JSON parsing (200 lines)
-└── LoggingMixin.ts              // $log, $logError (100 lines)
-```
-
-#### 3. `HomeView.vue` (1,852 lines) ⚠️ **MODERATE PRIORITY**
-**Issues Identified:**
-- **Multiple Concerns**: Activity feed, projects, contacts, notifications in one file
-- **Complex State Management**: 20+ reactive properties with interdependencies
-- **Mixed Lifecycle Logic**: Mount, update, and destroy logic intertwined
-
-### File Size Distribution Analysis
-```
-Files > 1000 lines: 9 files (4.6% of codebase)
-Files 500-1000 lines: 23 files (11.7% of codebase)  
-Files 200-500 lines: 45 files (22.8% of codebase)
-Files < 200 lines: 120 files (60.9% of codebase)
-```
-
-**Assessment**: Good distribution with most files reasonably sized, but critical outliers need attention.
-
-## Type Safety Analysis
-
-### Type Assertion Patterns
-
-#### "as any" Usage (62 total instances) ⚠️
-
-**Vue Components & Views (41 instances):**
-```typescript
-// ImageMethodDialog.vue:504
-const activeIdentity = await (this as any).$getActiveIdentity();
-
-// GiftedDialog.vue:228  
-const activeIdentity = await (this as any).$getActiveIdentity();
-
-// AccountViewView.vue: Multiple instances for:
-// - PlatformServiceMixin method access
-// - Vue refs with complex typing
-// - External library integration (Leaflet)
-```
-
-**Other Files (21 instances):**
-- **Vue Component References** (23 instances): `(this.$refs.dialog as any)`
-- **Platform Detection** (12 instances): `(navigator as any).standalone`
-- **External Library Integration** (15 instances): Leaflet, Axios extensions
-- **Legacy Code Compatibility** (8 instances): Temporary migration code
-- **Event Handler Workarounds** (4 instances): Vue event typing issues
-
-**Example Problematic Pattern:**
-```typescript
-// src/views/AccountViewView.vue:934
-const iconDefault = L.Icon.Default.prototype as unknown as Record<string, unknown>;
-
-// Better approach:
-interface LeafletIconPrototype {
-  _getIconUrl?: unknown;
-}
-const iconDefault = L.Icon.Default.prototype as LeafletIconPrototype;
-```
-
-#### "unknown" Type Usage (755 instances)
-**Analysis**: Generally good practice showing defensive programming, but some areas could benefit from more specific typing.
-
-### Recommended Type Safety Improvements
-
-1. **Create Interface Extensions**:
-```typescript
-// src/types/platform-service-mixin.ts
-interface VueWithPlatformServiceMixin extends Vue {
-  $getActiveIdentity(): Promise<{ activeDid: string }>;
-  $saveSettings(changes: Partial<Settings>): Promise<boolean>;
-  // ... other methods
-}
-
-// src/types/external.ts
-declare global {
-  interface Navigator {
-    standalone?: boolean;
-  }
-}
-
-interface VueRefWithOpen {
-  open: (callback: (result?: unknown) => void) => void;
-}
-```
-
-2. **Component Ref Typing**:
-```typescript
-// Instead of: (this.$refs.dialog as any).open()
-// Use: (this.$refs.dialog as VueRefWithOpen).open()
-```
-
-## Error Handling Consistency Analysis
-
-### Error Handling Patterns (367 catch blocks)
-
-#### Pattern Distribution:
-1. **Structured Logging** (85%): Uses logger.error with context
-2. **User Notification** (78%): Shows user-friendly error messages  
-3. **Graceful Degradation** (92%): Provides fallback behavior
-4. **Error Propagation** (45%): Re-throws when appropriate
-
-#### Excellent Pattern Example:
-```typescript
-// src/views/AccountViewView.vue:1617
-try {
-  const response = await this.axios.delete(url, { headers });
-  if (response.status === 204) {
-    this.profileImageUrl = "";
-    this.notify.success("Image deleted successfully.");
-  }
-} catch (error) {
-  if (isApiError(error) && error.response?.status === 404) {
-    // Graceful handling - image already gone
-    this.profileImageUrl = "";
-  } else {
-    this.notify.error("Failed to delete image", TIMEOUTS.STANDARD);
-  }
-}
-```
-
-#### Areas for Improvement:
-1. **Inconsistent Error Typing**: Some catch(error: any), others catch(error: unknown)
-2. **Missing Error Boundaries**: No Vue error boundary components
-3. **Silent Failures**: 15% of catch blocks don't notify users
-
-## Code Duplication Analysis
-
-### Significant Duplication Patterns
-
-#### 1. **Toggle Component Pattern** (12 occurrences)
-```html
-<!-- Repeated across multiple files -->
-<div class="relative ml-2 cursor-pointer" @click="toggleMethod()">
-  <input v-model="property" type="checkbox" class="sr-only" />
-  <div class="block bg-slate-500 w-14 h-8 rounded-full"></div>
-  <div class="dot absolute left-1 top-1 bg-slate-400 w-6 h-6 rounded-full transition"></div>
-</div>
-```
-
-**Solution**: Create `ToggleSwitch.vue` component with props for value, label, and change handler.
-
-#### 2. **API Error Handling Pattern** (25 occurrences)
-```typescript
-try {
-  const response = await this.axios.post(url, data, { headers });
-  if (response.status === 200) {
-    this.notify.success("Operation successful");
-  }
-} catch (error) {
-  if (isApiError(error)) {
-    this.notify.error(`Failed: ${error.message}`);
-  }
-}
-```
-
-**Solution**: Create `ApiRequestMixin.ts` with standardized request/response handling.
-
-#### 3. **Settings Update Pattern** (40+ occurrences)
-```typescript
-async methodName() {
-  await this.$saveSettings({ property: this.newValue });
-  this.property = this.newValue;
-}
-```
-
-**Solution**: Enhanced PlatformServiceMixin already provides `$saveSettings()` - migrate remaining manual patterns.
-
-## Dependency and Coupling Analysis
-
-### Import Dependency Patterns
-
-#### Legacy Database Coupling (EXCELLENT)
-- **Status**: 99.5% resolved (1 remaining databaseUtil import)
-- **Remaining**: `src/views/DeepLinkErrorView.vue:import { logConsoleAndDb }`
-- **Resolution**: Replace with PlatformServiceMixin `$logAndConsole()`
-
-#### Circular Dependency Status (EXCELLENT)
-- **Status**: 100% resolved, no active circular dependencies
-- **Previous Issues**: All resolved through PlatformServiceMixin architecture
-
-#### Component Coupling Analysis
-```typescript
-// High coupling components (>10 imports)
-AccountViewView.vue: 15 imports (understandable given scope)
-HomeView.vue: 12 imports 
-ProjectViewView.vue: 11 imports
-
-// Well-isolated components (<5 imports)  
-QuickActionViews: 3-4 imports each
-Component utilities: 2-3 imports each
-```
-
-**Assessment**: Reasonable coupling levels with clear architectural boundaries.
-
-## Console Logging Analysis (129 instances)
-
-### Logging Pattern Distribution:
-1. **console.log**: 89 instances (69%)
-2. **console.warn**: 24 instances (19%)  
-3. **console.error**: 16 instances (12%)
-
-### Vue Components & Views Logging (3 instances):
-- **Components**: 1 console.* call
-- **Views**: 2 console.* calls
-
-### Inconsistent Logging Approach:
-```typescript
-// Mixed patterns found:
-console.log("Direct console logging");           // 89 instances
-logger.debug("Structured logging");              // Preferred pattern
-this.$logAndConsole("Mixin logging");           // PlatformServiceMixin
-```
-
-### Recommended Standardization:
-1. **Migration Strategy**: Replace all console.* with logger.* calls
-2. **Structured Context**: Add consistent metadata to log entries
-3. **Log Levels**: Standardize debug/info/warn/error usage
-
-## Technical Debt Analysis (6 total)
-
-### Components (1 TODO):
-```typescript
-// PushNotificationPermission.vue
-// TODO: secretDB functionality needs to be migrated to PlatformServiceMixin
-```
-
-### Views (2 TODOs):
-```typescript
-// AccountViewView.vue
-// TODO: Implement this for SQLite
-// TODO: implement this for SQLite
-```
-
-### Other Files (3 TODOs):
-```typescript
-// src/db/tables/accounts.ts
-// TODO: When finished with migration, move these fields to Account and move identity and mnemonic here.
-
-// src/util.d.ts
-// TODO: , inspect: inspect
-
-// src/libs/crypto/vc/passkeyHelpers.ts
-// TODO: If it's after February 2025 when you read this then consider whether it still makes sense
-```
-
-**Assessment**: **EXCELLENT** - Only 6 TODO comments across 291 files.
-
-## Performance Anti-Patterns
-
-### Identified Issues:
-
-#### 1. **Excessive Reactive Properties**
-```typescript
-// AccountViewView.vue has 25+ reactive properties
-// Many could be computed or moved to component state
-```
-
-#### 2. **Inline Method Calls in Templates**
-```html
-<!-- Anti-pattern: -->
-<span>{{ readableDate(timeStr) }}</span>
-
-<!-- Better: -->
-<span>{{ readableTime }}</span>
-<!-- With computed property -->
-```
-
-#### 3. **Missing Key Attributes in Lists**
-```html
-<!-- Several v-for loops missing :key attributes -->
-<li v-for="item in items">
-```
-
-#### 4. **Complex Template Logic**
-```html
-<!-- AccountViewView.vue - Complex nested conditions -->
-<div v-if="!activeDid" id="noticeBeforeShare" class="bg-amber-200...">
-  <p class="mb-4">
-    <b>Note:</b> Before you can share with others or take any action, you need an identifier.
-  </p>
-  <router-link :to="{ name: 'new-identifier' }" class="inline-block...">
-    Create An Identifier
-  </router-link>
-</div>
-
-<!-- Identity Details -->
-<IdentitySection
-  :given-name="givenName"
-  :profile-image-url="profileImageUrl"
-  :active-did="activeDid"
-  :is-registered="isRegistered"
-  :show-large-identicon-id="showLargeIdenticonId"
-  :show-large-identicon-url="showLargeIdenticonUrl"
-  :show-did-copy="showDidCopy"
-  @edit-name="onEditName"
-  @show-qr-code="onShowQrCode"
-  @add-image="onAddImage"
-  @delete-image="onDeleteImage"
-  @show-large-identicon-id="onShowLargeIdenticonId"
-  @show-large-identicon-url="onShowLargeIdenticonUrl"
-/>
-```
-
-## Specific Actionable Recommendations
-
-### Priority 1: Critical File Refactoring
-
-1. **Split AccountViewView.vue**:
-   - **Timeline**: 2-3 sprints
-   - **Strategy**: Extract 6 major sections into focused components
-   - **Risk**: Medium (requires careful state management coordination)
-   - **Benefit**: Massive maintainability improvement, easier testing
-
-2. **Decompose ImageMethodDialog.vue**:
-   - **Timeline**: 2-3 sprints
-   - **Strategy**: Extract 6 focused components (camera, file upload, cropping, etc.)
-   - **Risk**: Medium (complex camera state management)
-   - **Benefit**: Massive maintainability improvement
-
-3. **Decompose PlatformServiceMixin.ts**:
-   - **Timeline**: 1-2 sprints  
-   - **Strategy**: Create focused mixins by concern area
-   - **Risk**: Low (well-defined interfaces already exist)
-   - **Benefit**: Better code organization, reduced cognitive load
-
-### Priority 2: Component Extraction
-
-1. **HomeView.vue** → 4 focused sections
-   - **Timeline**: 1-2 sprints
-   - **Risk**: Low (clear separation of concerns)
-   - **Benefit**: Better code organization
-
-2. **ProjectViewView.vue** → 4 focused sections
-   - **Timeline**: 1-2 sprints
-   - **Risk**: Low (well-defined boundaries)
-   - **Benefit**: Improved maintainability
-
-### Priority 3: Shared Component Creation
-
-1. **CameraPreviewComponent.vue**
-   - Extract from ImageMethodDialog.vue and PhotoDialog.vue
-   - **Benefit**: Eliminate code duplication
-
-2. **FileUploadComponent.vue**
-   - Extract from ImageMethodDialog.vue and PhotoDialog.vue
-   - **Benefit**: Consistent file handling
-
-3. **ToggleSwitch.vue**
-   - Replace 12 duplicate toggle patterns
-   - **Benefit**: Consistent UI components
-
-4. **DiagnosticsPanelComponent.vue**
-   - Extract from ImageMethodDialog.vue
-   - **Benefit**: Reusable debugging component
-
-### Priority 4: Type Safety Enhancement
-
-1. **Eliminate "as any" Assertions**:
-   - **Timeline**: 1 sprint
-   - **Strategy**: Create proper interface extensions
-   - **Risk**: Low
-   - **Benefit**: Better compile-time error detection
-
-2. **Standardize Error Typing**:
-   - **Timeline**: 0.5 sprint
-   - **Strategy**: Use consistent `catch (error: unknown)` pattern
-   - **Risk**: None
-   - **Benefit**: Better error handling consistency
-
-### Priority 5: State Management Optimization
-
-1. **Create Composables for Complex State**:
-```typescript
-// src/composables/useCameraState.ts
-export function useCameraState() {
-  const cameraState = ref<CameraState>("off");
-  const showPreview = ref(false);
-  const isRetrying = ref(false);
-  
-  const startCamera = async () => { /* ... */ };
-  const stopCamera = () => { /* ... */ };
-  
-  return { cameraState, showPreview, isRetrying, startCamera, stopCamera };
-}
-```
-
-2. **Group Related Reactive Properties**:
-```typescript
-// Instead of:
-showB64Copy: boolean = false;
-showDidCopy: boolean = false;
-showDerCopy: boolean = false;
-showPubCopy: boolean = false;
-
-// Use:
-copyStates = {
-  b64: false,
-  did: false,
-  der: false,
-  pub: false
-};
-```
-
-### Priority 6: Code Standardization
-
-1. **Logging Standardization**:
-   - **Timeline**: 1 sprint
-   - **Strategy**: Replace all console.* with logger.*
-   - **Risk**: None
-   - **Benefit**: Consistent logging, better debugging
-
-2. **Template Optimization**:
-   - Add missing `:key` attributes
-   - Convert inline method calls to computed properties
-   - Implement virtual scrolling for large lists
-
-## Quality Metrics Summary
-
-### Vue Component Quality Distribution:
-| Size Category | Count | Percentage | Quality Assessment |
-|---------------|-------|------------|-------------------|
-| Large (>500 lines) | 5 | 12.5% | 🔴 Needs Refactoring |
-| Medium (200-500 lines) | 12 | 30% | 🟡 Good with Minor Issues |
-| Small (<200 lines) | 23 | 57.5% | 🟢 Excellent |
-
-### Vue View Quality Distribution:
-| Size Category | Count | Percentage | Quality Assessment |
-|---------------|-------|------------|-------------------|
-| Large (>1000 lines) | 9 | 16.7% | 🔴 Needs Refactoring |
-| Medium (500-1000 lines) | 8 | 14.8% | 🟡 Good with Minor Issues |
-| Small (<500 lines) | 37 | 68.5% | 🟢 Excellent |
-
-### Overall Quality Metrics:
-| Metric | Components | Views | Overall Assessment |
-|--------|------------|-------|-------------------|
-| Technical Debt | 1 TODO | 2 TODOs | 🟢 Excellent |
-| Type Safety | 6 "as any" | 35 "as any" | 🟡 Good |
-| Console Logging | 1 instance | 2 instances | 🟢 Excellent |
-| Architecture Consistency | 100% | 100% | 🟢 Excellent |
-| Component Reuse | High | High | 🟢 Excellent |
-
-### Before vs. Target State:
-| Metric | Current | Target | Status |
-|--------|---------|---------|---------|
-| Files >1000 lines | 9 files | 3 files | 🟡 Needs Work |
-| "as any" assertions | 62 | 15 | 🟡 Moderate |
-| Console.* calls | 129 | 0 | 🔴 Needs Work |
-| Component reuse | 40% | 75% | 🟡 Moderate |
-| Error consistency | 85% | 95% | 🟢 Good |
-| Type coverage | 88% | 95% | 🟢 Good |
-
-## Risk Assessment
-
-### Low Risk Improvements (High Impact):
-- Logging standardization
-- Type assertion cleanup  
-- Missing key attributes
-- Component extraction from AccountViewView.vue
-- Shared component creation (ToggleSwitch, CameraPreview)
-
-### Medium Risk Improvements:
-- PlatformServiceMixin decomposition
-- State management optimization
-- ImageMethodDialog decomposition
-
-### High Risk Items:
-- None identified - project demonstrates excellent architectural discipline
-
-## Conclusion
-
-The TimeSafari codebase demonstrates **exceptional code quality** with:
-
-**Key Strengths:**
-- **Consistent Architecture**: 100% Vue 3 Composition API with TypeScript
-- **Minimal Technical Debt**: Only 6 TODO comments across 291 files
-- **Excellent Small Components**: 68.5% of views and 57.5% of components are well-sized
-- **Strong Type Safety**: Minimal "as any" usage, mostly justified
-- **Clean Logging**: Minimal console.* usage, structured logging preferred
-- **Excellent Database Migration**: 99.5% complete
-- **Comprehensive Error Handling**: 367 catch blocks with good coverage
-- **No Circular Dependencies**: 100% resolved
-
-**Primary Focus Areas:**
-1. **Decompose Large Files**: 5 components and 9 views need refactoring
-2. **Extract Shared Components**: Camera, file upload, and diagnostics components
-3. **Optimize State Management**: Group related properties and create composables
-4. **Improve Type Safety**: Create proper interface extensions for mixin methods
-5. **Logging Standardization**: Replace 129 console.* calls with structured logger.*
-
-**The component architecture is production-ready** with these improvements representing **strategic optimization** rather than critical fixes. The codebase demonstrates **mature Vue.js development practices** with excellent separation of concerns and consistent patterns.
-
----
-
-**Investigation Methodology:**
-- Static analysis of 291 source files (197 general + 94 Vue components/views)
-- Pattern recognition across 104,527 lines of code
-- Manual review of large files and complexity patterns
-- Dependency analysis and coupling assessment
-- Performance anti-pattern identification
-- Architecture consistency evaluation

README-PR-TEMPLATE.md

@@ -66,14 +66,17 @@ test-image.tar  a1b2c3d4e5f6...
 ```
 
 ### Docs
+
 - [x] **BUILDING.md** updated (sections): Docker deployment
 - [x] Troubleshooting updated: Added Docker troubleshooting section
 
 ### Rollback
+
 - [x] Verified steps to restore previous behavior:
   1. `git revert HEAD`
   2. `docker rmi test-image`
   3. Restore previous BUILDING.md
+
 ```
 
 ---

README.md

@@ -11,35 +11,14 @@ See [ClickUp](https://sharing.clickup.com/9014278710/l/h/8cmnyhp-174/10573fec74e
 
 Quick start:
 
-* For setup, we recommend [pkgx](https://pkgx.dev), which installs what you need (either automatically or with the `dev` command). Core dependencies are typescript & npm; when building for other platforms, you'll need other things such as those in the pkgx.yaml & BUILDING.md files.
+- For setup, we recommend [pkgx](https://pkgx.dev), which installs what you need (either automatically or with the `dev` command). Core dependencies are typescript & npm; when building for other platforms, you'll need other things such as those in the pkgx.yaml & BUILDING.md files.
 
 ```bash
 npm install
+npm run build:web:serve -- --test
 ```
 
-### Web
-
-```bash
-npm run build:web:dev
-```
-
-Then go to [the test page](http://localhost:8080/test) and click "Become User 0" to take action on the platform.
-
-### Android
-
-```bash
-npm run build:android:test:run
-```
-
-Assumes ADB is installed; see [Android Build](BUILDING.md#android-build) for SDK, emulator, and `PATH` setup.
-
-### iOS
-
-```bash
-npm run build:ios:studio
-```
-
-Assumes Xcode and Xcode Command Line Tools are installed.
+To be able to take action on the platform: go to [the test page](http://localhost:8080/test) and click "Become User 0".
 
 See [BUILDING.md](BUILDING.md) for comprehensive build instructions for all platforms (Web, Electron, iOS, Android, Docker).
 
@@ -89,16 +68,16 @@ TimeSafari supports configurable logging levels via the `VITE_LOG_LEVEL` environ
 
 ```bash
 # Show only errors
-VITE_LOG_LEVEL=error npm run build:web:dev
+VITE_LOG_LEVEL=error npm run dev
 
 # Show warnings and errors
-VITE_LOG_LEVEL=warn npm run build:web:dev
+VITE_LOG_LEVEL=warn npm run dev
 
 # Show info, warnings, and errors (default)
-VITE_LOG_LEVEL=info npm run build:web:dev
+VITE_LOG_LEVEL=info npm run dev
 
 # Show all log levels including debug
-VITE_LOG_LEVEL=debug npm run build:web:dev
+VITE_LOG_LEVEL=debug npm run dev
 ```
 
 ### Available Levels
@@ -110,28 +89,8 @@ VITE_LOG_LEVEL=debug npm run build:web:dev
 
 See [Logging Configuration Guide](doc/logging-configuration.md) for complete details.
 
-## Notification Debug Panel (dev builds)
-
-In non-production bundles (for example `vite dev` or a Vite build whose mode is not `production`), the **Notification Debug Panel** at `/dev/notifications` helps you test notification registration, backend refresh, WAKEUP_PING handling, and local schedule inspection on native builds.
-
-**Access:** **Account** → enable **Show All General Advanced Functions** → **Notification Debug Panel**.
-
-Key configuration (independent settings):
-
-- **Notification Backend URL** — which notification server receives API calls
-- **Test Mode** — `testMode` sent in JSON request bodies (default on)
-- **Skip JWT Authentication (Local Development Only)** — omit JWT headers for local unauthenticated backends (default off)
-
-See [doc/notification-debug-panel.md](doc/notification-debug-panel.md) for controls, recommended settings (hosted test server vs local ngrok), and troubleshooting.
-
-Platform-specific end-to-end guides:
-
-- [doc/local-android-testing-ngrok.md](doc/local-android-testing-ngrok.md)
-- [doc/local-ios-testing-ngrok.md](doc/local-ios-testing-ngrok.md)
-
-## Database Clearing (development)
-
 ### Quick Usage
+
 ```bash
 # Run the database clearing script
 ./scripts/clear-database.sh
@@ -144,16 +103,19 @@ npm run build:web:dev       # For Web
 ### What It Does
 
 #### **Electron (Desktop App)**
+
 - Automatically finds and clears the SQLite database files
 - Works on Linux, macOS, and Windows
 - Clears all data and forces fresh migrations on next startup
 
 #### **Web Browser**
+
 - Provides instructions for using custom browser data directories
 - Shows manual clearing via browser DevTools
 - Ensures reliable database clearing without browser complications
 
 ### Safety Features
+
 - ✅ **Interactive Script**: Guides you through the process
 - ✅ **Platform Detection**: Automatically detects your OS
 - ✅ **Clear Instructions**: Step-by-step guidance for each platform
@@ -162,6 +124,7 @@ npm run build:web:dev       # For Web
 ### Manual Commands (if needed)
 
 #### **Electron Database Location**
+
 ```bash
 # Linux
 rm -rf ~/.config/TimeSafari/*
@@ -174,6 +137,7 @@ rmdir /s /q %APPDATA%\TimeSafari
 ```
 
 #### **Web Browser (Custom Data Directory)**
+
 ```bash
 # Create isolated browser profile
 mkdir ~/timesafari-dev-data
@@ -186,6 +150,7 @@ URL generation across all environments. This prevents localhost URLs from
 appearing in shared links during development.
 
 ### Key Features
+
 - ✅ **Production URLs for Sharing**: All copy link buttons use production domain
 - ✅ **Environment-Specific Internal URLs**: Internal operations use appropriate
   environment URLs
@@ -269,6 +234,7 @@ npm run test:prerequisites
 - **Build failures**: Run `npm run check:dependencies` to diagnose environment issues
 
 **Required Versions**:
+
 - Node.js: 18+ (LTS recommended)
 - npm: 8+ (comes with Node.js)
 - Platform-specific tools: Android Studio, Xcode (for mobile builds)
@@ -288,25 +254,26 @@ To add a Font Awesome icon, add to `fontawesome.ts` and reference with
 
 ### Reference Material
 
-* Notifications can be type of `toast` (self-dismiss), `info`, `success`, `warning`, and `danger`.
+- Notifications can be type of `toast` (self-dismiss), `info`, `success`, `warning`, and `danger`.
   They are done via [notiwind](https://www.npmjs.com/package/notiwind) and set up in App.vue.
 
-* [Customize Vue configuration](https://cli.vuejs.org/config/).
+- [Customize Vue configuration](https://cli.vuejs.org/config/).
 
-* If you are deploying in a subdirectory, add it to `publicPath` in vue.config.js, eg: `publicPath: "/app/time-tracker/",`
+- If you are deploying in a subdirectory, add it to `publicPath` in vue.config.js, eg: `publicPath: "/app/time-tracker/",`
 
 ### Code Organization
 
 The project uses a centralized approach to type definitions and interfaces:
 
-* `src/interfaces/` - Contains all TypeScript interfaces and type definitions
-  * `deepLinks.ts` - Deep linking type system and Zod validation schemas
-  * `give.ts` - Give-related interfaces and type definitions
-  * `claims.ts` - Claim-related interfaces and verifiable credentials
-  * `common.ts` - Shared interfaces and utility types
-  * Other domain-specific interface files
+- `src/interfaces/` - Contains all TypeScript interfaces and type definitions
+  - `deepLinks.ts` - Deep linking type system and Zod validation schemas
+  - `give.ts` - Give-related interfaces and type definitions
+  - `claims.ts` - Claim-related interfaces and verifiable credentials
+  - `common.ts` - Shared interfaces and utility types
+  - Other domain-specific interface files
 
 Key principles:
+
 - All interfaces and types are defined in the interfaces folder
 - Zod schemas are used for runtime validation and type generation
 - Domain-specific interfaces are separated into their own files
@@ -317,15 +284,17 @@ Key principles:
 
 The application uses a platform-agnostic database layer with Vue mixins for service access:
 
-* `src/services/PlatformService.ts` - Database interface definition
-* `src/services/PlatformServiceFactory.ts` - Platform-specific service factory
-* `src/services/AbsurdSqlDatabaseService.ts` - SQLite implementation
-* `src/utils/PlatformServiceMixin.ts` - Vue mixin for database access with caching
+- `src/services/PlatformService.ts` - Database interface definition
+- `src/services/PlatformServiceFactory.ts` - Platform-specific service factory
+- `src/services/AbsurdSqlDatabaseService.ts` - SQLite implementation
+- `src/utils/PlatformServiceMixin.ts` - Vue mixin for database access with caching
+- `src/db/` - Legacy Dexie database (migration in progress)
 
 **Development Guidelines**:
 
 - Always use `PlatformServiceMixin` for database operations in components
 - Test with PlatformServiceMixin for new features
+- Use migration tools for data transfer between systems
 - Leverage mixin's ultra-concise methods: `$db()`, `$exec()`, `$one()`, `$contacts()`, `$settings()`
 
 **Architecture Decision**: The project uses Vue mixins over Composition API composables for platform service access. See [Architecture Decisions](doc/architecture-decisions.md) for detailed rationale.
@@ -348,6 +317,7 @@ timesafari/
 ## 🤝 Contributing
 
 1. **Follow the Build Architecture Guard** - Update BUILDING.md when modifying build files
+2. **Use the PR template** - Complete the checklist for build-related changes
 3. **Test your changes** - Ensure builds work on affected platforms
 4. **Document updates** - Keep BUILDING.md current and accurate
 
@@ -355,11 +325,11 @@ timesafari/
 
 Gifts make the world go 'round!
 
-* [WebStorm by JetBrains](https://www.jetbrains.com/webstorm/) for the free open-source license
-* [Máximo Fernández](https://medium.com/@maxfarenas) for the 3D [code](https://github.com/maxfer03/vue-three-ns) and [explanatory post](https://medium.com/nicasource/building-an-interactive-web-portfolio-with-vue-three-js-part-three-implementing-three-js-452cb375ef80)
-* [Many tools & libraries](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/src/branch/master/package.json#L10) such as Nodejs.org, IntelliJ Idea, Veramo.io, Vuejs.org, threejs.org
-* [Bush 3D model](https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439)
-* [Forest floor image](https://www.goodfreephotos.com/albums/textures/leafy-autumn-forest-floor.jpg)
-* Time Safari logo assisted by [DALL-E in ChatGPT](https://chat.openai.com/g/g-2fkFE8rbu-dall-e)
-* [DiceBear](https://www.dicebear.com/licenses/) and [Avataaars](https://www.dicebear.com/styles/avataaars/#details) for human-looking identicons
-* Some gratitude prompts thanks to [Develop Good Habits](https://www.developgoodhabits.com/gratitude-journal-prompts/)
+- [WebStorm by JetBrains](https://www.jetbrains.com/webstorm/) for the free open-source license
+- [Máximo Fernández](https://medium.com/@maxfarenas) for the 3D [code](https://github.com/maxfer03/vue-three-ns) and [explanatory post](https://medium.com/nicasource/building-an-interactive-web-portfolio-with-vue-three-js-part-three-implementing-three-js-452cb375ef80)
+- [Many tools & libraries](https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/src/branch/master/package.json#L10) such as Nodejs.org, IntelliJ Idea, Veramo.io, Vuejs.org, threejs.org
+- [Bush 3D model](https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439)
+- [Forest floor image](https://www.goodfreephotos.com/albums/textures/leafy-autumn-forest-floor.jpg)
+- Time Safari logo assisted by [DALL-E in ChatGPT](https://chat.openai.com/g/g-2fkFE8rbu-dall-e)
+- [DiceBear](https://www.dicebear.com/licenses/) and [Avataaars](https://www.dicebear.com/styles/avataaars/#details) for human-looking identicons
+- Some gratitude prompts thanks to [Develop Good Habits](https://www.developgoodhabits.com/gratitude-journal-prompts/)

TASK_storage.md

@@ -5,33 +5,33 @@
 
 We can't trust iOS IndexedDB to persist. I want to start delivering an app to people now, in preparation for presentations mid-June: Rotary on June 12 and Porcfest on June 17.
 
-* Apple WebKit puts a [7-day cap on IndexedDB](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/).
+- Apple WebKit puts a [7-day cap on IndexedDB](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/).
 
-  * The web standards expose a `persist` method to mark memory as persistent, and [supposedly WebView supports it](https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persisted), but too many other things indicate it's not reliable. I've talked with [ChatGPT](https://chatgpt.com/share/68322f40-84c8-8007-b213-855f7962989a) & Venice & Claude (in Cursor); [this answer from Perplexity](https://www.perplexity.ai/search/which-platforms-prompt-the-use-HUQLqy4qQD2cRbkmO4CgHg) says that most platforms don't prompt and Safari doesn't support it; I don't know if that means WebKit as well.
+  - The web standards expose a `persist` method to mark memory as persistent, and [supposedly WebView supports it](https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persisted), but too many other things indicate it's not reliable. I've talked with [ChatGPT](https://chatgpt.com/share/68322f40-84c8-8007-b213-855f7962989a) & Venice & Claude (in Cursor); [this answer from Perplexity](https://www.perplexity.ai/search/which-platforms-prompt-the-use-HUQLqy4qQD2cRbkmO4CgHg) says that most platforms don't prompt and Safari doesn't support it; I don't know if that means WebKit as well.
 
-* Capacitor says [not to trust it on iOS](https://capacitorjs.com/docs/v6/guides/storage).
+- Capacitor says [not to trust it on iOS](https://capacitorjs.com/docs/v6/guides/storage).
 
 Also, with sensitive data, the accounts info should be encrypted.
 
 # Options
 
-* There is a community [SQLite plugin for Capacitor](https://github.com/capacitor-community/sqlite) with encryption by [SQLCipher](https://github.com/sqlcipher/sqlcipher).
+- There is a community [SQLite plugin for Capacitor](https://github.com/capacitor-community/sqlite) with encryption by [SQLCipher](https://github.com/sqlcipher/sqlcipher).
 
-  * [This tutorial](https://jepiqueau.github.io/2023/09/05/Ionic7Vue-SQLite-CRUD-App.html#part-1---web---table-of-contents) shows how that plugin works for web as well as native.
+  - [This tutorial](https://jepiqueau.github.io/2023/09/05/Ionic7Vue-SQLite-CRUD-App.html#part-1---web---table-of-contents) shows how that plugin works for web as well as native.
 
-* Capacitor abstracts [user preferences in an API](https://capacitorjs.com/docs/apis/preferences), which uses different underlying libraries on iOS & Android. Unfortunately, it won't do any filtering or searching, and is only meant for small amounts of data. (It could be used for settings and for identifiers, but contacts will grow and image blobs won't work.)
+- Capacitor abstracts [user preferences in an API](https://capacitorjs.com/docs/apis/preferences), which uses different underlying libraries on iOS & Android. Unfortunately, it won't do any filtering or searching, and is only meant for small amounts of data. (It could be used for settings and for identifiers, but contacts will grow and image blobs won't work.)
 
-  * There are hints that Capacitor offers another custom storage API but all I could find was that Preferences API.
+  - There are hints that Capacitor offers another custom storage API but all I could find was that Preferences API.
 
-* [Ionic Storage](https://ionic.io/docs/secure-storage) is an enterprise solution, which also supports encryption.
+- [Ionic Storage](https://ionic.io/docs/secure-storage) is an enterprise solution, which also supports encryption.
 
-* Not an option yet: Dexie may support SQLite in [a future version](https://dexie.org/roadmap/dexie5.0).
+- Not an option yet: Dexie may support SQLite in [a future version](https://dexie.org/roadmap/dexie5.0).
 
 # Current Plan
 
-* Implement SQLite for Capacitor & web, with encryption. That will allow us to test quickly and keep the same interface for native & web, but we don't deal with migrations for current web users.
+- Implement SQLite for Capacitor & web, with encryption. That will allow us to test quickly and keep the same interface for native & web, but we don't deal with migrations for current web users.
 
-* After that is delivered, write a migration for current web users from IndexedDB to SQLite.
+- After that is delivered, write a migration for current web users from IndexedDB to SQLite.
 
 # Current method calls
 

android/app/build.gradle

@@ -27,18 +27,12 @@ if (!project.ext.MY_KEYSTORE_FILE) {
 android {
     namespace 'app.timesafari'
     compileSdk rootProject.ext.compileSdkVersion
-
-    compileOptions {
-        sourceCompatibility JavaVersion.VERSION_17
-        targetCompatibility JavaVersion.VERSION_17
-    }
-
     defaultConfig {
         applicationId "app.timesafari.app"
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
-        versionCode 66
-        versionName "1.4.1"
+        versionCode 40
+        versionName "1.0.7"
         testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
         aaptOptions {
              // Files and dirs to omit from the packaged assets dir, modified to accommodate modern web apps.
@@ -107,20 +101,6 @@ dependencies {
     implementation project(':capacitor-android')
     implementation project(':capacitor-community-sqlite')
     implementation "androidx.biometric:biometric:1.2.0-alpha05"
-
-    // Daily Notification Plugin dependencies
-    implementation "androidx.room:room-runtime:2.6.1"
-    implementation "androidx.work:work-runtime-ktx:2.9.0"
-    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3"
-    annotationProcessor "androidx.room:room-compiler:2.6.1"
-
-    // Capacitor annotation processor for automatic plugin discovery
-    annotationProcessor project(':capacitor-android')
-
-    // Additional dependencies for notification plugin
-    implementation 'androidx.lifecycle:lifecycle-service:2.7.0'
-    implementation 'com.google.code.gson:gson:2.10.1'
-
     testImplementation "junit:junit:$junitVersion"
     androidTestImplementation "androidx.test.ext:junit:$androidxJunitVersion"
     androidTestImplementation "androidx.test.espresso:espresso-core:$androidxEspressoCoreVersion"

android/app/capacitor.build.gradle

@@ -15,12 +15,9 @@ dependencies {
     implementation project(':capacitor-camera')
     implementation project(':capacitor-clipboard')
     implementation project(':capacitor-filesystem')
-    implementation project(':capacitor-preferences')
-    implementation project(':capacitor-push-notifications')
     implementation project(':capacitor-share')
     implementation project(':capacitor-status-bar')
     implementation project(':capawesome-capacitor-file-picker')
-    implementation project(':timesafari-daily-notification-plugin')
 
 }
 

android/app/google-services.json

@@ -1,13 +1,13 @@
 {
   "project_info": {
-    "project_number": "1094643115061",
-    "project_id": "pc-api-7249509642322112640-286",
-    "storage_bucket": "pc-api-7249509642322112640-286.firebasestorage.app"
+    "project_number": "123456789000",
+    "project_id": "timesafari-app",
+    "storage_bucket": "timesafari-app.appspot.com"
   },
   "client": [
     {
       "client_info": {
-        "mobilesdk_app_id": "1:1094643115061:android:f11bd26f6bd2fcdc887d7c",
+        "mobilesdk_app_id": "1:123456789000:android:1234567890abcdef",
         "android_client_info": {
           "package_name": "app.timesafari.app"
         }
@@ -15,45 +15,7 @@
       "oauth_client": [],
       "api_key": [
         {
-          "current_key": "AIzaSyCFLYeLfGQqh7ErvzXgy74H0Gx3yQAMEw8"
-        }
-      ],
-      "services": {
-        "appinvite_service": {
-          "other_platform_oauth_client": []
-        }
-      }
-    },
-    {
-      "client_info": {
-        "mobilesdk_app_id": "1:1094643115061:android:354e70007466b006887d7c",
-        "android_client_info": {
-          "package_name": "ch.endorser.mobile"
-        }
-      },
-      "oauth_client": [],
-      "api_key": [
-        {
-          "current_key": "AIzaSyCFLYeLfGQqh7ErvzXgy74H0Gx3yQAMEw8"
-        }
-      ],
-      "services": {
-        "appinvite_service": {
-          "other_platform_oauth_client": []
-        }
-      }
-    },
-    {
-      "client_info": {
-        "mobilesdk_app_id": "1:1094643115061:android:40b63cb5851f34ac887d7c",
-        "android_client_info": {
-          "package_name": "com.veramo_react_native"
-        }
-      },
-      "oauth_client": [],
-      "api_key": [
-        {
-          "current_key": "AIzaSyCFLYeLfGQqh7ErvzXgy74H0Gx3yQAMEw8"
+          "current_key": "AIzaSyDummyKeyForBuildPurposesOnly12345"
         }
       ],
       "services": {
@@ -62,6 +24,5 @@
         }
       }
     }
-  ],
-  "configuration_version": "1"
-}
+  ]
+} 

android/app/src/main/AndroidManifest.xml

@@ -1,12 +1,10 @@
 <?xml version="1.0" encoding="utf-8" ?>
 <manifest xmlns:android="http://schemas.android.com/apk/res/android">
     <application
-        android:name=".TimeSafariApplication"
         android:allowBackup="true"
         android:icon="@mipmap/ic_launcher"
         android:label="@string/app_name"
         android:roundIcon="@mipmap/ic_launcher_round"
-        android:networkSecurityConfig="@xml/network_security_config"
         android:supportsRtl="true"
         android:theme="@style/AppTheme">
         <activity
@@ -29,59 +27,8 @@
                 <category android:name="android.intent.category.BROWSABLE" />
                 <data android:scheme="timesafari" />
             </intent-filter>
-
-            <!-- Share Target Intent Filter - Single Image -->
-            <intent-filter>
-                <action android:name="android.intent.action.SEND" />
-                <category android:name="android.intent.category.DEFAULT" />
-                <data android:mimeType="image/*" />
-            </intent-filter>
-
-            <!-- Share Target Intent Filter - Multiple Images (optional, we'll handle first image) -->
-            <intent-filter>
-                <action android:name="android.intent.action.SEND_MULTIPLE" />
-                <category android:name="android.intent.category.DEFAULT" />
-                <data android:mimeType="image/*" />
-            </intent-filter>
         </activity>
 
-        <!-- Daily Notification Plugin Receivers (must be inside application) -->
-        <!-- DailyNotificationReceiver: Handles alarm-triggered notifications -->
-        <!-- Note: exported="true" allows AlarmManager to trigger this receiver -->
-        <receiver
-            android:name="org.timesafari.dailynotification.DailyNotificationReceiver"
-            android:enabled="true"
-            android:exported="false">
-            <intent-filter>
-                <action android:name="org.timesafari.daily.NOTIFICATION" />
-            </intent-filter>
-        </receiver>
-
-        <!-- NotifyReceiver: Handles notification delivery -->
-        <receiver
-            android:name="org.timesafari.dailynotification.NotifyReceiver"
-            android:enabled="true"
-            android:exported="false"
-        />
-
-        <!-- BootReceiver: reschedule daily notification after device restart.
-             Two intent-filters: BOOT_COMPLETED has no Uri, so must not share a filter with <data scheme="package"/> or the boot broadcast never matches. -->
-        <receiver
-            android:name="org.timesafari.dailynotification.BootReceiver"
-            android:enabled="true"
-            android:exported="true"
-            android:directBootAware="true">
-            <intent-filter android:priority="1000">
-                <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" />
-                <action android:name="android.intent.action.BOOT_COMPLETED" />
-            </intent-filter>
-            <intent-filter android:priority="1000">
-                <action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
-                <action android:name="android.intent.action.PACKAGE_REPLACED" />
-                <data android:scheme="package" />
-            </intent-filter>
-        </receiver>
-
         <provider
             android:name="androidx.core.content.FileProvider"
             android:authorities="${applicationId}.fileprovider"
@@ -98,14 +45,4 @@
     <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
     <uses-permission android:name="android.permission.CAMERA" />
     <uses-feature android:name="android.hardware.camera" android:required="true" />
-
-    <!-- Daily Notification Plugin Permissions -->
-    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
-    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
-    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
-    <uses-permission android:name="android.permission.WAKE_LOCK" />
-    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
-    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
-    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
-    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
 </manifest>

android/app/src/main/assets/capacitor.config.json

@@ -16,13 +16,6 @@
 				]
 			}
 		},
-		"PushNotifications": {
-			"presentationOptions": [
-				"badge",
-				"sound",
-				"alert"
-			]
-		},
 		"SplashScreen": {
 			"launchShowDuration": 3000,
 			"launchAutoHide": true,
@@ -49,31 +42,6 @@
 				"biometricTitle": "Biometric login for TimeSafari"
 			},
 			"electronIsEncryption": false
-		},
-		"DailyNotification": {
-			"debugMode": true,
-			"enableNotifications": true,
-			"timesafariConfig": {
-				"activeDid": "",
-				"endpoints": {
-					"projectsLastUpdated": "https://api.endorser.ch/api/v2/report/plansLastUpdatedBetween"
-				},
-				"starredProjectsConfig": {
-					"enabled": true,
-					"starredPlanHandleIds": [],
-					"fetchInterval": "0 8 * * *"
-				}
-			},
-			"networkConfig": {
-				"timeout": 30000,
-				"retryAttempts": 3,
-				"retryDelay": 1000
-			},
-			"contentFetch": {
-				"enabled": true,
-				"schedule": "0 8 * * *",
-				"fetchLeadTimeMinutes": 5
-			}
 		}
 	},
 	"ios": {

android/app/src/main/assets/capacitor.plugins.json

@@ -23,14 +23,6 @@
 		"pkg": "@capacitor/filesystem",
 		"classpath": "com.capacitorjs.plugins.filesystem.FilesystemPlugin"
 	},
-	{
-		"pkg": "@capacitor/preferences",
-		"classpath": "com.capacitorjs.plugins.preferences.PreferencesPlugin"
-	},
-	{
-		"pkg": "@capacitor/push-notifications",
-		"classpath": "com.capacitorjs.plugins.pushnotifications.PushNotificationsPlugin"
-	},
 	{
 		"pkg": "@capacitor/share",
 		"classpath": "com.capacitorjs.plugins.share.SharePlugin"
@@ -42,17 +34,5 @@
 	{
 		"pkg": "@capawesome/capacitor-file-picker",
 		"classpath": "io.capawesome.capacitorjs.plugins.filepicker.FilePickerPlugin"
-	},
-	{
-		"pkg": "@timesafari/daily-notification-plugin",
-		"classpath": "org.timesafari.dailynotification.DailyNotificationPlugin"
-	},
-	{
-		"pkg": "SafeArea",
-		"classpath": "app.timesafari.safearea.SafeAreaPlugin"
-	},
-	{
-		"pkg": "SharedImage",
-		"classpath": "app.timesafari.sharedimage.SharedImagePlugin"
 	}
 ]

android/app/src/main/java/app/timesafari/MainActivity.java

@@ -1,10 +1,6 @@
 package app.timesafari;
 
-import android.content.Intent;
-import android.net.Uri;
 import android.os.Bundle;
-import android.util.Base64;
-import android.util.Log;
 import android.view.View;
 import android.view.WindowManager;
 import android.view.WindowInsetsController;
@@ -15,22 +11,9 @@ import android.webkit.WebSettings;
 import android.webkit.WebViewClient;
 import com.getcapacitor.BridgeActivity;
 import app.timesafari.safearea.SafeAreaPlugin;
-import app.timesafari.sharedimage.SharedImagePlugin;
-import app.timesafari.notifications.NotificationInspectorPlugin;
 //import com.getcapacitor.community.sqlite.SQLite;
 
-import android.content.SharedPreferences;
-import java.io.InputStream;
-import java.io.ByteArrayOutputStream;
-import java.io.IOException;
-
 public class MainActivity extends BridgeActivity {
-    private static final String TAG = "MainActivity";
-    private static final String SHARED_PREFS_NAME = "shared_image";
-    private static final String KEY_BASE64 = "shared_image_base64";
-    private static final String KEY_FILE_NAME = "shared_image_file_name";
-    private static final String KEY_READY = "shared_image_ready";
-    
     @Override
     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
@@ -65,167 +48,9 @@ public class MainActivity extends BridgeActivity {
         // Register SafeArea plugin
         registerPlugin(SafeAreaPlugin.class);
         
-        // Register SharedImage plugin
-        registerPlugin(SharedImagePlugin.class);
-
-        // Register NotificationInspector plugin (dev tooling; safe no-op on Android)
-        registerPlugin(NotificationInspectorPlugin.class);
-        
-        // Register DailyNotification plugin
-        // Plugin is written in Kotlin but compiles to Java-compatible bytecode
-        registerPlugin(org.timesafari.dailynotification.DailyNotificationPlugin.class);
-
-        // Register native content fetcher for API-driven daily notifications (Endorser.ch)
-        org.timesafari.dailynotification.DailyNotificationPlugin.setNativeFetcher(
-            new TimeSafariNativeFetcher(this));
-        
         // Initialize SQLite
         //registerPlugin(SQLite.class);
-        
-        // Handle share intent if app was launched from share sheet
-        handleShareIntent(getIntent());
     }
     
-    @Override
-    protected void onNewIntent(Intent intent) {
-        super.onNewIntent(intent);
-        setIntent(intent);
-        handleShareIntent(intent);
-    }
-    
-    /**
-     * Handle share intents (ACTION_SEND or ACTION_SEND_MULTIPLE)
-     * Processes shared images and stores them in SharedPreferences for plugin to read
-     */
-    private void handleShareIntent(Intent intent) {
-        if (intent == null) {
-            return;
-        }
-        
-        String action = intent.getAction();
-        String type = intent.getType();
-        
-        boolean handled = false;
-        
-        // Handle single image share
-        if (Intent.ACTION_SEND.equals(action) && type != null && type.startsWith("image/")) {
-            Uri imageUri;
-            // Use new API for API 33+ (Android 13+), fall back to deprecated API for older versions
-            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
-                imageUri = intent.getParcelableExtra(Intent.EXTRA_STREAM, Uri.class);
-            } else {
-                // Deprecated but still works on older versions
-                @SuppressWarnings("deprecation")
-                Uri uri = intent.getParcelableExtra(Intent.EXTRA_STREAM);
-                imageUri = uri;
-            }
-            if (imageUri != null) {
-                String fileName = intent.getStringExtra(Intent.EXTRA_TEXT);
-                processSharedImage(imageUri, fileName);
-                handled = true;
-            }
-        }
-        // Handle multiple images share (we'll just process the first one)
-        else if (Intent.ACTION_SEND_MULTIPLE.equals(action) && type != null && type.startsWith("image/")) {
-            java.util.ArrayList<Uri> imageUris;
-            // Use new API for API 33+ (Android 13+), fall back to deprecated API for older versions
-            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
-                imageUris = intent.getParcelableArrayListExtra(Intent.EXTRA_STREAM, Uri.class);
-            } else {
-                // Deprecated but still works on older versions
-                @SuppressWarnings("deprecation")
-                java.util.ArrayList<Uri> uris = intent.getParcelableArrayListExtra(Intent.EXTRA_STREAM);
-                imageUris = uris;
-            }
-            if (imageUris != null && !imageUris.isEmpty()) {
-                processSharedImage(imageUris.get(0), null);
-                handled = true;
-            }
-        }
-        
-        // Clear the intent after handling to release URI permissions and prevent
-        // network issues in WebView. This is critical for preventing the WebView
-        // from losing network connectivity after processing shared content.
-        if (handled) {
-            intent.setAction(null);
-            intent.setData(null);
-            intent.removeExtra(Intent.EXTRA_STREAM);
-            intent.setType(null);
-            setIntent(new Intent());
-            Log.d(TAG, "Cleared share intent after processing");
-        }
-    }
-    
-    /**
-     * Process a shared image: read it, convert to base64, and write to temp file
-     * Uses try-with-resources to ensure proper stream cleanup and prevent network issues
-     */
-    private void processSharedImage(Uri imageUri, String fileName) {
-        // Extract filename from URI or use default (do this before opening streams)
-        String actualFileName = fileName;
-        if (actualFileName == null || actualFileName.isEmpty()) {
-            String path = imageUri.getPath();
-            if (path != null) {
-                int lastSlash = path.lastIndexOf('/');
-                if (lastSlash >= 0 && lastSlash < path.length() - 1) {
-                    actualFileName = path.substring(lastSlash + 1);
-                }
-            }
-            if (actualFileName == null || actualFileName.isEmpty()) {
-                actualFileName = "shared-image.jpg";
-            }
-        }
-        
-        // Use try-with-resources to ensure streams are properly closed
-        // This is critical to prevent resource leaks that can affect WebView networking
-        try (InputStream inputStream = getContentResolver().openInputStream(imageUri);
-             ByteArrayOutputStream buffer = new ByteArrayOutputStream()) {
-            
-            if (inputStream == null) {
-                Log.e(TAG, "Failed to open input stream for shared image");
-                return;
-            }
-            
-            // Read image bytes
-            byte[] data = new byte[8192];
-            int nRead;
-            while ((nRead = inputStream.read(data, 0, data.length)) != -1) {
-                buffer.write(data, 0, nRead);
-            }
-            buffer.flush();
-            byte[] imageBytes = buffer.toByteArray();
-            
-            // Convert to base64
-            String base64String = Base64.encodeToString(imageBytes, Base64.NO_WRAP);
-            
-            // Store in SharedPreferences for plugin to read
-            storeSharedImageInPreferences(base64String, actualFileName);
-            
-            Log.d(TAG, "Successfully processed shared image: " + actualFileName);
-        } catch (IOException e) {
-            Log.e(TAG, "Error processing shared image", e);
-        } catch (Exception e) {
-            Log.e(TAG, "Unexpected error processing shared image", e);
-        }
-    }
-    
-    /**
-     * Store shared image data in SharedPreferences for plugin to read
-     * Plugin will read and clear the data when called
-     */
-    private void storeSharedImageInPreferences(String base64, String fileName) {
-        try {
-            SharedPreferences prefs = getSharedPreferences(SHARED_PREFS_NAME, MODE_PRIVATE);
-            SharedPreferences.Editor editor = prefs.edit();
-            editor.putString(KEY_BASE64, base64);
-            editor.putString(KEY_FILE_NAME, fileName);
-            editor.putBoolean(KEY_READY, true);
-            editor.apply();
-            
-            Log.d(TAG, "Stored shared image data in SharedPreferences");
-        } catch (Exception e) {
-            Log.e(TAG, "Error storing shared image in SharedPreferences", e);
-        }
-    }
 
 } 

android/app/src/main/java/app/timesafari/TimeSafariApplication.java

@@ -1,27 +0,0 @@
-package app.timesafari;
-
-import android.app.Application;
-import android.content.Context;
-import android.util.Log;
-import org.timesafari.dailynotification.DailyNotificationPlugin;
-import org.timesafari.dailynotification.NativeNotificationContentFetcher;
-
-public class TimeSafariApplication extends Application {
-
-    private static final String TAG = "TimeSafariApplication";
-
-    @Override
-    public void onCreate() {
-        super.onCreate();
-
-        Log.i(TAG, "Initializing TimeSafari notifications");
-
-        // Register native fetcher with application context
-        Context context = getApplicationContext();
-        NativeNotificationContentFetcher fetcher =
-            new TimeSafariNativeFetcher(context);
-        DailyNotificationPlugin.setNativeFetcher(fetcher);
-
-        Log.i(TAG, "Native fetcher registered");
-    }
-}

android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java

@@ -1,395 +0,0 @@
-package app.timesafari;
-
-import android.content.Context;
-import android.content.SharedPreferences;
-import android.util.Log;
-
-import androidx.annotation.NonNull;
-import androidx.annotation.Nullable;
-
-import com.google.gson.Gson;
-import com.google.gson.JsonArray;
-import com.google.gson.JsonObject;
-import com.google.gson.JsonParser;
-
-import org.timesafari.dailynotification.FetchContext;
-import org.timesafari.dailynotification.NativeNotificationContentFetcher;
-import org.timesafari.dailynotification.NotificationContent;
-
-import java.io.BufferedReader;
-import java.io.IOException;
-import java.io.InputStream;
-import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.net.HttpURLConnection;
-import java.net.URL;
-import java.nio.charset.StandardCharsets;
-import java.util.ArrayList;
-import java.util.Collections;
-import java.util.HashMap;
-import java.util.List;
-import java.util.Map;
-import java.util.concurrent.CompletableFuture;
-
-/**
- * Native content fetcher for API-driven daily notifications.
- * Calls Endorser.ch plansLastUpdatedBetween with configured credentials and
- * starred plan IDs (from plugin's updateStarredPlans), then returns notification content.
- */
-public class TimeSafariNativeFetcher implements NativeNotificationContentFetcher {
-
-    private static final String TAG = "TimeSafariNativeFetcher";
-    private static final String ENDORSER_ENDPOINT = "/api/v2/report/plansLastUpdatedBetween";
-    private static final int CONNECT_TIMEOUT_MS = 10000;
-    private static final int READ_TIMEOUT_MS = 15000;
-    private static final int MAX_RETRIES = 3;
-    /** Max chars of response body logged at DEBUG (avoids huge log lines). */
-    private static final int MAX_RESPONSE_BODY_LOG_CHARS = 4096;
-    private static final int RETRY_DELAY_MS = 1000;
-
-    // Must match plugin's SharedPreferences name and keys (DailyNotificationPlugin / TimeSafariIntegrationManager)
-    private static final String PREFS_NAME = "daily_notification_timesafari";
-    private static final String KEY_STARRED_PLAN_IDS = "starredPlanIds";
-    private static final String KEY_LAST_ACKED_JWT_ID = "last_acked_jwt_id";
-
-    private final Gson gson = new Gson();
-    private final Context appContext;
-    private final SharedPreferences prefs;
-
-    private volatile String apiBaseUrl;
-    private volatile String activeDid;
-    private volatile String jwtToken;
-    /** Distinct JWTs from configureNativeFetcher `jwtTokens`; null = use jwtToken only. */
-    @Nullable
-    private List<String> jwtTokenPool;
-
-    public TimeSafariNativeFetcher(Context context) {
-        this.appContext = context.getApplicationContext();
-        this.prefs = appContext.getSharedPreferences(PREFS_NAME, Context.MODE_PRIVATE);
-    }
-
-    @Override
-    public void configure(String apiBaseUrl, String activeDid, String jwtToken) {
-        configure(apiBaseUrl, activeDid, jwtToken, null);
-    }
-
-    @Override
-    public void configure(
-            String apiBaseUrl,
-            String activeDid,
-            String jwtToken,
-            @Nullable List<String> jwtTokenPool) {
-        this.apiBaseUrl = apiBaseUrl;
-        this.activeDid = activeDid;
-        this.jwtToken = jwtToken;
-        this.jwtTokenPool =
-                jwtTokenPool != null && !jwtTokenPool.isEmpty()
-                        ? new ArrayList<>(jwtTokenPool)
-                        : null;
-        int starredCount = getStarredPlanIds().size();
-        Log.i(
-                TAG,
-                "Configured with API: "
-                        + apiBaseUrl
-                        + ", starredPlanIds count="
-                        + starredCount
-                        + (this.jwtTokenPool != null
-                                ? ", jwtPoolSize=" + this.jwtTokenPool.size()
-                                : ""));
-    }
-
-    /** One pool entry per UTC day (epoch day mod pool size); else primary jwtToken. */
-    private String selectBearerTokenForRequest() {
-        List<String> pool = jwtTokenPool;
-        if (pool == null || pool.isEmpty()) {
-            return jwtToken;
-        }
-        long epochDay = System.currentTimeMillis() / (24L * 60 * 60 * 1000);
-        int idx = (int) (epochDay % pool.size());
-        String t = pool.get(idx);
-        if (t == null || t.isEmpty()) {
-            return jwtToken;
-        }
-        Log.i(TAG, "Bearer from JWT pool: index=" + idx + " of " + pool.size());
-        return t;
-    }
-
-    @NonNull
-    @Override
-    public CompletableFuture<List<NotificationContent>> fetchContent(@NonNull FetchContext fetchContext) {
-        Long scheduled = fetchContext.scheduledTime;
-        Log.i(
-                TAG,
-                "fetchContent START trigger="
-                        + fetchContext.trigger
-                        + " scheduledTime="
-                        + (scheduled != null ? scheduled : "null")
-                        + " callerThread="
-                        + Thread.currentThread().getName());
-        Log.d(TAG, "Fetching notification content, trigger: " + fetchContext.trigger);
-        return fetchContentWithRetry(fetchContext, 0);
-    }
-
-    private CompletableFuture<List<NotificationContent>> fetchContentWithRetry(
-            @NonNull FetchContext context, int retryCount) {
-        return CompletableFuture.supplyAsync(() -> {
-            try {
-                Log.i(TAG, "fetchContent worker thread=" + Thread.currentThread().getName());
-                String bearer = selectBearerTokenForRequest();
-                if (apiBaseUrl == null || activeDid == null || bearer == null || bearer.isEmpty()) {
-                    Log.e(TAG, "Not configured. Call configureNativeFetcher() from TypeScript first.");
-                    return Collections.emptyList();
-                }
-
-                String urlString = apiBaseUrl + ENDORSER_ENDPOINT;
-                URL url = new URL(urlString);
-                HttpURLConnection connection = (HttpURLConnection) url.openConnection();
-                connection.setConnectTimeout(CONNECT_TIMEOUT_MS);
-                connection.setReadTimeout(READ_TIMEOUT_MS);
-                connection.setRequestMethod("POST");
-                connection.setRequestProperty("Content-Type", "application/json");
-                connection.setRequestProperty("Authorization", "Bearer " + bearer);
-                connection.setDoOutput(true);
-
-                Map<String, Object> requestBody = new HashMap<>();
-                List<String> planIds = getStarredPlanIds();
-                requestBody.put("planIds", planIds);
-                String afterId = getLastAcknowledgedJwtId();
-                if (afterId == null || afterId.isEmpty()) {
-                    afterId = "0";
-                }
-                requestBody.put("afterId", afterId);
-                Log.i(
-                        TAG,
-                        "POST "
-                                + ENDORSER_ENDPOINT
-                                + " planCount="
-                                + planIds.size()
-                                + " afterId="
-                                + (afterId.length() > 12 ? afterId.substring(0, 12) + "…" : afterId));
-
-                String jsonBody = gson.toJson(requestBody);
-                try (OutputStream os = connection.getOutputStream()) {
-                    byte[] input = jsonBody.getBytes(StandardCharsets.UTF_8);
-                    os.write(input, 0, input.length);
-                }
-
-                int responseCode = connection.getResponseCode();
-                Log.i(TAG, "HTTP response code: " + responseCode);
-
-                if (responseCode == 200) {
-                    StringBuilder response = new StringBuilder();
-                    try (BufferedReader reader = new BufferedReader(
-                            new InputStreamReader(connection.getInputStream(), StandardCharsets.UTF_8))) {
-                        String line;
-                        while ((line = reader.readLine()) != null) {
-                            response.append(line);
-                        }
-                    }
-                    String responseBody = response.toString();
-                    String snippet =
-                            responseBody.length() <= MAX_RESPONSE_BODY_LOG_CHARS
-                                    ? responseBody
-                                    : responseBody.substring(0, MAX_RESPONSE_BODY_LOG_CHARS) + "…";
-                    Log.d(
-                            TAG,
-                            "plansLastUpdatedBetween response len="
-                                    + responseBody.length()
-                                    + " body="
-                                    + snippet);
-                    List<NotificationContent> contents = parseApiResponse(responseBody, context);
-                    if (!contents.isEmpty()) {
-                        updateLastAckedJwtIdFromResponse(responseBody);
-                    }
-                    Log.i(TAG, "Fetched " + contents.size() + " notification(s)");
-                    return contents;
-                }
-
-                if (retryCount < MAX_RETRIES && (responseCode >= 500 || responseCode == 429)) {
-                    int delayMs = RETRY_DELAY_MS * (1 << retryCount);
-                    String errBody = readHttpErrorBodySnippet(connection);
-                    Log.w(
-                            TAG,
-                            "Retryable error "
-                                    + responseCode
-                                    + (errBody.isEmpty() ? "" : " body: " + errBody)
-                                    + ", retrying in "
-                                    + delayMs
-                                    + "ms");
-                    try {
-                        Thread.sleep(delayMs);
-                    } catch (InterruptedException e) {
-                        Thread.currentThread().interrupt();
-                        return Collections.emptyList();
-                    }
-                    return fetchContentWithRetry(context, retryCount + 1).join();
-                }
-
-                String errBody = readHttpErrorBodySnippet(connection);
-                if (errBody.isEmpty()) {
-                    Log.e(TAG, "API error " + responseCode);
-                } else {
-                    Log.e(TAG, "API error " + responseCode + " body: " + errBody);
-                }
-                return Collections.emptyList();
-            } catch (Exception e) {
-                Log.e(TAG, "Fetch failed", e);
-                if (retryCount < MAX_RETRIES) {
-                    try {
-                        Thread.sleep(RETRY_DELAY_MS * (1 << retryCount));
-                    } catch (InterruptedException ie) {
-                        Thread.currentThread().interrupt();
-                        return Collections.emptyList();
-                    }
-                    return fetchContentWithRetry(context, retryCount + 1).join();
-                }
-                return Collections.emptyList();
-            }
-        });
-    }
-
-    /**
-     * Reads error response body for logging (HttpURLConnection puts 4xx/5xx bodies on
-     * {@link HttpURLConnection#getErrorStream()}).
-     */
-    private static String readHttpErrorBodySnippet(HttpURLConnection connection) {
-        InputStream stream = connection.getErrorStream();
-        if (stream == null) {
-            return "";
-        }
-        final int maxChars = 4096;
-        try (BufferedReader reader =
-                new BufferedReader(new InputStreamReader(stream, StandardCharsets.UTF_8))) {
-            StringBuilder sb = new StringBuilder();
-            String line;
-            while ((line = reader.readLine()) != null) {
-                if (sb.length() > 0) {
-                    sb.append('\n');
-                }
-                if (sb.length() + line.length() > maxChars) {
-                    sb.append(line, 0, Math.max(0, maxChars - sb.length()));
-                    sb.append("…");
-                    break;
-                }
-                sb.append(line);
-            }
-            return sb.toString().trim();
-        } catch (IOException e) {
-            return "(read error body failed: " + e.getMessage() + ")";
-        }
-    }
-
-    private List<String> getStarredPlanIds() {
-        try {
-            String idsJson = prefs.getString(KEY_STARRED_PLAN_IDS, "[]");
-            if (idsJson == null || idsJson.isEmpty() || "[]".equals(idsJson)) {
-                return new ArrayList<>();
-            }
-            JsonArray arr = JsonParser.parseString(idsJson).getAsJsonArray();
-            List<String> list = new ArrayList<>();
-            for (int i = 0; i < arr.size(); i++) {
-                list.add(arr.get(i).getAsString());
-            }
-            return list;
-        } catch (Exception e) {
-            Log.e(TAG, "Error loading starred plan IDs", e);
-            return new ArrayList<>();
-        }
-    }
-
-    private String getLastAcknowledgedJwtId() {
-        return prefs.getString(KEY_LAST_ACKED_JWT_ID, null);
-    }
-
-    private void updateLastAckedJwtIdFromResponse(String responseBody) {
-        try {
-            JsonObject root = JsonParser.parseString(responseBody).getAsJsonObject();
-            if (!root.has("data")) return;
-            JsonArray dataArray = root.getAsJsonArray("data");
-            if (dataArray == null || dataArray.size() == 0) return;
-            JsonObject lastItem = dataArray.get(dataArray.size() - 1).getAsJsonObject();
-            String jwtId = null;
-            if (lastItem.has("jwtId")) {
-                jwtId = lastItem.get("jwtId").getAsString();
-            } else if (lastItem.has("plan")) {
-                JsonObject plan = lastItem.getAsJsonObject("plan");
-                if (plan.has("jwtId")) {
-                    jwtId = plan.get("jwtId").getAsString();
-                }
-            }
-            if (jwtId != null && !jwtId.isEmpty()) {
-                prefs.edit().putString(KEY_LAST_ACKED_JWT_ID, jwtId).apply();
-            }
-        } catch (Exception e) {
-            Log.w(TAG, "Could not extract JWT ID from response", e);
-        }
-    }
-
-    /**
-     * Display title for a plansLastUpdatedBetween row; prefers {@code plan.name}, else "Unnamed Project".
-     */
-    private String extractProjectDisplayTitle(JsonObject item) {
-        if (item.has("plan")) {
-            JsonObject plan = item.getAsJsonObject("plan");
-            if (plan.has("name") && !plan.get("name").isJsonNull()) {
-                String name = plan.get("name").getAsString();
-                if (name != null && !name.trim().isEmpty()) {
-                    return name.trim();
-                }
-            }
-        }
-        return "Unnamed Project";
-    }
-
-    @Nullable
-    private String extractJwtIdFromItem(JsonObject item) {
-        if (item.has("plan")) {
-            JsonObject plan = item.getAsJsonObject("plan");
-            if (plan.has("jwtId") && !plan.get("jwtId").isJsonNull()) {
-                return plan.get("jwtId").getAsString();
-            }
-        }
-        if (item.has("jwtId") && !item.get("jwtId").isJsonNull()) {
-            return item.get("jwtId").getAsString();
-        }
-        return null;
-    }
-
-    private List<NotificationContent> parseApiResponse(String responseBody, FetchContext context) {
-        List<NotificationContent> contents = new ArrayList<>();
-        try {
-            JsonObject root = JsonParser.parseString(responseBody).getAsJsonObject();
-            JsonArray dataArray = root.has("data") ? root.getAsJsonArray("data") : null;
-            if (dataArray == null || dataArray.size() == 0) {
-                return contents;
-            }
-
-            JsonObject firstItem = dataArray.get(0).getAsJsonObject();
-            String firstTitle = extractProjectDisplayTitle(firstItem);
-            String jwtId = extractJwtIdFromItem(firstItem);
-
-            NotificationContent content = new NotificationContent();
-            content.setId("endorser_" + (jwtId != null ? jwtId : ("batch_" + System.currentTimeMillis())));
-            int n = dataArray.size();
-            String quotedFirst = "\u201C" + firstTitle + "\u201D";
-            if (n == 1) {
-                content.setTitle("Starred Project Update");
-                content.setBody(quotedFirst + " has been updated.");
-            } else {
-                content.setTitle("Starred Project Updates");
-                int more = n - 1;
-                content.setBody(quotedFirst + " + " + more + " more have been updated.");
-            }
-            content.setScheduledTime(
-                    context.scheduledTime != null
-                            ? context.scheduledTime
-                            : (System.currentTimeMillis() + 3600000));
-            content.setPriority("default");
-            content.setSound(true);
-            contents.add(content);
-        } catch (Exception e) {
-            Log.e(TAG, "Error parsing API response", e);
-        }
-        return contents;
-    }
-}

android/app/src/main/java/app/timesafari/notifications/NotificationInspectorPlugin.java

@@ -1,16 +0,0 @@
-package app.timesafari.notifications;
-
-import com.getcapacitor.Plugin;
-import com.getcapacitor.PluginCall;
-import com.getcapacitor.PluginMethod;
-import com.getcapacitor.annotation.CapacitorPlugin;
-
-@CapacitorPlugin(name = "NotificationInspector")
-public class NotificationInspectorPlugin extends Plugin {
-  @PluginMethod
-  public void getPendingNotifications(PluginCall call) {
-    call.unimplemented(
-        "Pending notification inspection is currently implemented on iOS only");
-  }
-}
-

android/app/src/main/java/app/timesafari/sharedimage/SharedImagePlugin.java

@@ -1,84 +0,0 @@
-package app.timesafari.sharedimage;
-
-import android.content.Context;
-import android.content.SharedPreferences;
-import com.getcapacitor.JSObject;
-import com.getcapacitor.Plugin;
-import com.getcapacitor.PluginCall;
-import com.getcapacitor.PluginMethod;
-import com.getcapacitor.annotation.CapacitorPlugin;
-
-@CapacitorPlugin(name = "SharedImage")
-public class SharedImagePlugin extends Plugin {
-    
-    private static final String SHARED_PREFS_NAME = "shared_image";
-    private static final String KEY_BASE64 = "shared_image_base64";
-    private static final String KEY_FILE_NAME = "shared_image_file_name";
-    private static final String KEY_READY = "shared_image_ready";
-    
-    /**
-     * Get shared image data from SharedPreferences
-     * Returns base64 string and fileName, or null if no image exists
-     * Clears the data after reading to prevent re-reading
-     */
-    @PluginMethod
-    public void getSharedImage(PluginCall call) {
-        try {
-            SharedPreferences prefs = getSharedPreferences();
-            
-            String base64 = prefs.getString(KEY_BASE64, null);
-            String fileName = prefs.getString(KEY_FILE_NAME, null);
-            
-            if (base64 == null || fileName == null) {
-                // No shared image exists - return null values (not an error)
-                JSObject result = new JSObject();
-                result.put("base64", (String) null);
-                result.put("fileName", (String) null);
-                call.resolve(result);
-                return;
-            }
-            
-            // Clear the shared data after reading
-            SharedPreferences.Editor editor = prefs.edit();
-            editor.remove(KEY_BASE64);
-            editor.remove(KEY_FILE_NAME);
-            editor.remove(KEY_READY);
-            editor.apply();
-            
-            // Return the shared image data
-            JSObject result = new JSObject();
-            result.put("base64", base64);
-            result.put("fileName", fileName);
-            call.resolve(result);
-        } catch (Exception e) {
-            android.util.Log.e("SharedImagePlugin", "Error in getSharedImage()", e);
-            call.reject("Error getting shared image: " + e.getMessage());
-        }
-    }
-    
-    /**
-     * Check if shared image exists without reading it
-     * Useful for quick checks before calling getSharedImage()
-     */
-    @PluginMethod
-    public void hasSharedImage(PluginCall call) {
-        SharedPreferences prefs = getSharedPreferences();
-        boolean hasImage = prefs.contains(KEY_BASE64) && prefs.contains(KEY_FILE_NAME);
-        
-        JSObject result = new JSObject();
-        result.put("hasImage", hasImage);
-        call.resolve(result);
-    }
-    
-    /**
-     * Get SharedPreferences instance for shared image data
-     */
-    private SharedPreferences getSharedPreferences() {
-        Context context = getContext();
-        if (context == null) {
-            throw new IllegalStateException("Plugin context is null");
-        }
-        return context.getSharedPreferences(SHARED_PREFS_NAME, Context.MODE_PRIVATE);
-    }
-}
-

android/app/src/main/res/xml/network_security_config.xml

@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<network-security-config>
-    <base-config cleartextTrafficPermitted="true">
-        <trust-anchors>
-            <certificates src="system" />
-        </trust-anchors>
-    </base-config>
-    <domain-config cleartextTrafficPermitted="true">
-        <domain includeSubdomains="true">localhost</domain>
-        <domain includeSubdomains="true">10.0.2.2</domain>
-    </domain-config>
-</network-security-config>

android/build.gradle

@@ -22,9 +22,6 @@ allprojects {
         google()
         mavenCentral()
     }
-    
-    // Note: KAPT JVM arguments for Java 17+ compatibility are configured in gradle.properties
-    // The org.gradle.jvmargs setting includes --add-opens flags needed for KAPT
 }
 
 task clean(type: Delete) {

android/capacitor.settings.gradle

@@ -20,12 +20,6 @@ project(':capacitor-clipboard').projectDir = new File('../node_modules/@capacito
 include ':capacitor-filesystem'
 project(':capacitor-filesystem').projectDir = new File('../node_modules/@capacitor/filesystem/android')
 
-include ':capacitor-preferences'
-project(':capacitor-preferences').projectDir = new File('../node_modules/@capacitor/preferences/android')
-
-include ':capacitor-push-notifications'
-project(':capacitor-push-notifications').projectDir = new File('../node_modules/@capacitor/push-notifications/android')
-
 include ':capacitor-share'
 project(':capacitor-share').projectDir = new File('../node_modules/@capacitor/share/android')
 
@@ -34,6 +28,3 @@ project(':capacitor-status-bar').projectDir = new File('../node_modules/@capacit
 
 include ':capawesome-capacitor-file-picker'
 project(':capawesome-capacitor-file-picker').projectDir = new File('../node_modules/@capawesome/capacitor-file-picker/android')
-
-include ':timesafari-daily-notification-plugin'
-project(':timesafari-daily-notification-plugin').projectDir = new File('../node_modules/@timesafari/daily-notification-plugin/android')

android/gradle.properties

@@ -9,8 +9,7 @@
 
 # Specifies the JVM arguments used for the daemon process.
 # The setting is particularly useful for tweaking memory settings.
-# Added --add-opens flags for KAPT compatibility with Java 17+
-org.gradle.jvmargs=-Xmx1536m --add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
+org.gradle.jvmargs=-Xmx1536m
 
 # When configured, Gradle will run in incubating parallel mode.
 # This option should only be used with decoupled projects. More details, visit

android/variables.gradle

@@ -1,5 +1,5 @@
 ext {
-    minSdkVersion = 23
+    minSdkVersion = 22
     compileSdkVersion = 36
     targetSdkVersion = 36
     androidxActivityVersion = '1.8.0'

capacitor.config.ts

@@ -18,9 +18,6 @@ const config: CapacitorConfig = {
         ]
       }
     },
-    PushNotifications: {
-      presentationOptions: ['badge', 'sound', 'alert']
-    },
     SplashScreen: {
       launchShowDuration: 3000,
       launchAutoHide: true,
@@ -47,31 +44,6 @@ const config: CapacitorConfig = {
         biometricTitle: 'Biometric login for TimeSafari'
       },
       electronIsEncryption: false
-    },
-    DailyNotification: {
-      debugMode: true,
-      enableNotifications: true,
-      timesafariConfig: {
-        activeDid: '', // Will be set dynamically from user's DID
-        endpoints: {
-          projectsLastUpdated: 'https://api.endorser.ch/api/v2/report/plansLastUpdatedBetween'
-        },
-        starredProjectsConfig: {
-          enabled: true,
-          starredPlanHandleIds: [],
-          fetchInterval: '0 8 * * *'
-        }
-      },
-      networkConfig: {
-        timeout: 30000,
-        retryAttempts: 3,
-        retryDelay: 1000
-      },
-      contentFetch: {
-        enabled: true,
-        schedule: '0 8 * * *',
-        fetchLeadTimeMinutes: 5
-      }
     }
   },
   ios: {

doc/DAILY_NOTIFICATION_BUG_DIAGNOSIS.md

@@ -1,120 +0,0 @@
-# Daily Notification Bugs — Diagnosis (Plugin + App)
-
-**Context:** Fixes were applied in both the plugin and the app, but "reset doesn't fire" and "notification text defaults to fallback" still occur. This doc summarizes what was checked and what to do next.
-
----
-
-## What Was Verified
-
-### App integration (correct)
-
-- **NativeNotificationService.ts**  
-  - Pre-cancel is gated: only iOS calls `cancelDailyReminder()` before scheduling (lines 289–305). Android skips it.  
-  - Schedules with `id: this.reminderId` (`"daily_timesafari_reminder"`), plus `time`, `title`, `body`.  
-  - Calls `DailyNotification.scheduleDailyNotification(scheduleOptions)` (not `scheduleDailyReminder`).
-
-- **AccountViewView.vue**  
-  - `editReminderNotification()` only calls `cancelDailyNotification()` when **not** Android (lines 1303–1305). On Android it only calls `scheduleDailyNotification()`.  
-
-So the app is not double-cancelling on Android and is passing the expected options.
-
-### Plugin in app’s node_modules (fixed code present)
-
-- **node_modules/@timesafari/daily-notification-plugin** is at **version 1.1.4** and contains:
-  - **NotifyReceiver.kt:** DB idempotence is skipped when `skipPendingIntentIdempotence=true` (wrapped in `if (!skipPendingIntentIdempotence)`).
-  - **DailyNotificationWorker.java:** `preserveStaticReminder` read from input, stable `scheduleId` for static reminders, and `scheduleExactNotification(..., preserveStaticReminder, ...)`.
-  - **DailyNotificationPlugin.kt:** `cancelDailyReminder(call)` implemented.
-
-So the **source** the app uses (from its dependency) already has the fixes.
-
-### Plugin schedule path (correct)
-
-- App calls `scheduleDailyNotification` → plugin’s `scheduleDailyNotification(call)` → `ScheduleHelper.scheduleDailyNotification(...)`.
-- That helper calls `NotifyReceiver.cancelNotification(context, scheduleId)` then `scheduleExactNotification(..., skipPendingIntentIdempotence = true)`.
-- So the “re-set” path does set `skipPendingIntentIdempotence = true` and the DB idempotence skip should apply.
-
----
-
-## Likely Causes Why Bugs Still Appear
-
-### 1. Stale Android build / old APK
-
-The Android app compiles the plugin from:
-
-`android/capacitor.settings.gradle` →  
-`project(':timesafari-daily-notification-plugin').projectDir = new File('../node_modules/@timesafari/daily-notification-plugin/android')`
-
-If the app was not fully rebuilt after the plugin in node_modules was updated, the running APK may still contain old plugin code.
-
-**Do this:**
-
-- In the **app** repo (`crowd-funder-for-time-pwa`):
-  - `./gradlew clean` (or Android Studio → Build → Clean Project)
-  - Build and reinstall the app (e.g. Run on device/emulator).
-- Confirm you’re not installing an older APK from somewhere else.
-
-### 2. Dependency not actually updated after plugin changes
-
-The app depends on:
-
-```json
-"@timesafari/daily-notification-plugin": "git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git#master"
-```
-
-If the fixes were only made in a **local clone** and never pushed to **gitea** `master`, then:
-
-- `npm install` / `npm update` in the app would not pull the fixes.
-- The app’s `node_modules` would only have the fixes if they were copied/linked from the fixed repo.
-
-**Do this:**
-
-- **Push** the fixed plugin to the official gitea repo (`trent_larson/daily-notification-plugin`), then in this app run `npm update @timesafari/daily-notification-plugin` (or set `package.json` to the branch/tag/commit you need), `npm install`, `npx cap sync android`, clean build and reinstall. The app should always depend on the published git remote, not a local `file:` path.
-
-### 3. Fallback text from native fetcher (Bug 2 only)
-
-**TimeSafariNativeFetcher.java** in the app is still a placeholder: it always returns:
-
-- Title: `"TimeSafari Update"`
-- Body: `"Check your starred projects for updates!"`
-
-That only affects flows that **fetch** content (e.g. prefetch or any path that uses the fetcher for display). The **static** daily reminder path does not use the fetcher for display: title/body come from the schedule Intent and WorkManager input. So if you only use the “daily reminder” (one time + custom title/body), the fetcher placeholder should not be the cause. If you have any flow that relies on **fetched** content for the text, you’ll see that placeholder until the fetcher is implemented and wired (and optionally token persistence).
-
----
-
-## Verification Steps (after clean build + reinstall)
-
-1. **Reset / “re-set” (Bug 1)**  
-   - Set reminder for 2–3 minutes from now.  
-   - Edit and save **without changing the time**.  
-   - Wait for the time; the notification should fire.  
-   - In logcat, filter by the plugin’s tags and look for:
-     - `Skipping DB idempotence (skipPendingIntentIdempotence=true) for scheduleId=...`
-     - `Scheduling next daily alarm: id=daily_timesafari_reminder ...`  
-   If you see these, the fixed path is running.
-
-2. **Static text on rollover (Bug 2)**  
-   - Set a custom title/body, let the notification fire once.  
-   - In logcat look for:
-     - `DN|ROLLOVER next=... scheduleId=daily_timesafari_reminder static=true`  
-   If you see `static=true` and the same `scheduleId`, the next occurrence should keep your custom text.
-
-3. **Plugin version at build time**  
-   - In the app’s `node_modules/@timesafari/daily-notification-plugin/package.json`, confirm `"version": "1.1.4"` (or the version that includes the fixes).  
-   - After that, a clean build ensures that version is what’s in the APK.
-
----
-
-## Summary
-
-| Check | Status |
-|-------|--------|
-| App gates cancel on Android | OK |
-| App calls scheduleDailyNotification with id/title/body | OK |
-| Plugin in app node_modules has DB idempotence skip | OK (1.1.4) |
-| Plugin in app node_modules has static rollover fix | OK |
-| Plugin in app node_modules has cancelDailyReminder | OK |
-| Schedule path passes skipPendingIntentIdempotence = true | OK |
-
-**See also:** `doc/plugin-feedback-android-rollover-double-fire-and-user-content.md` — when two notifications fire (e.g. one ~3 min early, one on the dot) and neither shows user-set content.
-
-Most likely the app is still running an **old Android build**. Do a **clean build and reinstall**, and ensure the plugin dependency in the app really points at the fixed code (gitea master or local path). Then re-test and check logcat for the lines above. If the bugs persist after that, the next step is to capture a full logcat from “edit reminder (same time)” through the next fire and from “first fire” through “next day” to see which path runs.

doc/DAILY_NOTIFICATION_DUPLICATE_FALLBACK_ANALYSIS.md

@@ -1,169 +0,0 @@
-# Daily Notification: Why Extra Notifications With Fallback / "Starred Projects" Still Fire
-
-**Date:** 2026-03-02  
-**Context:** After previous fixes (see `DAILY_NOTIFICATION_BUG_DIAGNOSIS.md` and `plugin-feedback-android-rollover-double-fire-and-user-content.md`), duplicate notifications and fallback/"starred projects" text still occur. This doc explains root causes and where fixes must happen.
-
----
-
-## Summary of What’s Happening
-
-1. **Extra notification(s)** fire at a different time (e.g. ~3 min early) or at the same time as the user-set one.
-2. **Wrong text** appears: either generic fallback ("Daily Update" / "Good morning! Ready to make today amazing?") or the app’s placeholder ("TimeSafari Update" / "Check your starred projects for updates!").
-3. The **correct** notification (user-set time and message) can still fire as well, so the user sees both correct and wrong notifications.
-
----
-
-## Root Causes
-
-### 1. Second alarm from prefetch (UUID / fallback)
-
-**Mechanism**
-
-- The plugin has two scheduling paths:
-  - **NotifyReceiver** (AlarmManager): used for the app’s single daily reminder; uses `scheduleId` (e.g. `daily_timesafari_reminder`) and carries title/body in the Intent.
-  - **DailyNotificationScheduler** (legacy): used by **DailyNotificationFetchWorker** when prefetch runs and then calls `scheduleNotificationIfNeeded(fallbackContent)`. That creates a **second** alarm with `notification_id` = **UUID** (from `createEmergencyFallbackContent()` or from fetcher placeholder).
-
-- **ScheduleHelper** correctly **does not** enqueue prefetch for static reminders (see comment in `DailyNotificationPlugin.kt` ~2686: "Do not enqueue prefetch for static reminders"). So **new** schedules from the app no longer create a prefetch job.
-
-- However:
-  - **Existing** WorkManager prefetch jobs (tag `daily_notification_fetch`) that were enqueued **before** that fix (or by an older build) are still pending. When they run, fetch fails or returns placeholder → `useFallbackContent()` → `scheduleNotificationIfNeeded(fallbackContent)` → **second alarm with UUID**.
-  - That UUID alarm is **not** stored in the Schedule table. So when the user later calls `scheduleDailyNotification`, **cleanupExistingNotificationSchedules** only cancels alarms for schedule IDs that exist in the DB (e.g. `daily_timesafari_reminder`, `daily_rollover_*`). The **UUID alarm is never cancelled**.
-
-- **Result:** You can have two alarms: one for `daily_timesafari_reminder` (correct) and one for a UUID (fallback text). If the UUID alarm was set for a slightly different time (e.g. from an old rollover), you get two notifications at two times.
-
-**Where the fallback text comes from (plugin)**
-
-- **DailyNotificationFetchWorker** (in both app’s `node_modules` plugin and the standalone repo):
-  - On failed fetch after max retries: `useFallbackContent(scheduledTime)` → `createEmergencyFallbackContent(scheduledTime)` → title "Daily Update", body "🌅 Good morning! Ready to make today amazing?".
-  - That content is saved and then **scheduled** via `scheduleNotificationIfNeeded(fallbackContent)`, which uses **DailyNotificationScheduler** (legacy) and assigns a **new UUID** to the content. So the second alarm fires with that UUID and shows that fallback text.
-
-### 2. Prefetch WorkManager jobs not cancelled when user reschedules
-
-- **scheduleDailyNotification** (plugin) calls:
-  - `ScheduleHelper.cleanupExistingNotificationSchedules(...)` → cancels **alarms** for all DB schedules (except current `scheduleId`).
-  - `ScheduleHelper.scheduleDailyNotification(...)` → cancels alarm for current `scheduleId`, schedules NotifyReceiver alarm, **does not** enqueue prefetch.
-
-- It does **not** cancel **WorkManager** jobs. So any already-enqueued prefetch work (tag `daily_notification_fetch`) remains. When that work runs, it creates the second (UUID) alarm as above.
-
-- **ScheduleHelper** has `cancelAllWorkManagerJobs(context)` (cancels tags `prefetch`, `daily_notification_fetch`, etc.), but **nothing calls it** in the schedule path. So pending prefetch jobs are left in place.
-
-**Fix (plugin):** When the app calls `scheduleDailyNotification`, **cancel all fetch-related WorkManager work** (e.g. call `ScheduleHelper.cancelAllWorkManagerJobs(context)` or a helper that only cancels `daily_notification_fetch` and `prefetch`) **before** or **right after** `cleanupExistingNotificationSchedules`. That prevents any pending prefetch from running and creating a UUID alarm later.
-
-### 3. "Starred projects" message from the app’s native fetcher
-
-- **TimeSafariNativeFetcher** (`android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`) is still a **placeholder**: it always returns:
-  - Title: `"TimeSafari Update"`
-  - Body: `"Check your starred projects for updates!"`
-
-- That text is used whenever the plugin **fetches** content and then displays it:
-  - **DailyNotificationFetchWorker**: on “successful” fetch it saves and schedules the fetcher’s result; for your app that result is the placeholder, so any notification created from that path shows “starred projects”.
-  - **DailyNotificationWorker** (JIT path): when `is_static_reminder` is false and content is loaded from Room by `notification_id`, if the worker then does a JIT refresh (e.g. content stale), it calls `DailyNotificationFetcher.fetchContentImmediately()` which can use the app’s native fetcher and **overwrite** title/body with the placeholder.
-
-- So “starred projects” appears on any notification that goes through a **fetch** path (prefetch success or JIT) instead of the **static reminder** path (Intent title/body or Room by canonical `schedule_id`).
-
-**Fix (app):** For a static-reminder-only flow, the plugin should not run prefetch (already done) and should not overwrite with fetcher in JIT for static reminders. Reducing duplicate/out-of-schedule alarms (fixes above) ensures the main run is the static one. Optionally, implement **TimeSafariNativeFetcher** to return real content if you ever want “fetch-based” notifications; until then, the only path that should show user text is the NotifyReceiver alarm with `daily_timesafari_reminder` and title/body from Intent or from Room by `schedule_id`.
-
-### 4. Rollover / Room content keyed by run-specific id
-
-- When an alarm fires with `notification_id` = **UUID** or **notify_<timestamp>** (and no or missing title/body in the Intent), the Worker treats it as **non-static**. It loads content from Room by that `notification_id`. The entity for `daily_timesafari_reminder` (user title/body) is stored under a **different** id, so the Worker either finds nothing or finds content written by prefetch/fallback for that run → wrong text.
-
-- When the alarm is the **correct** one (`daily_timesafari_reminder`) and Intent has title/body (or `schedule_id`), the Worker uses static reminder or resolves by `schedule_id` and shows user text. So the main fix is to **avoid creating the UUID/notify_* run in the first place** (cancel prefetch work; no second alarm). Rollover for the static reminder already passes `scheduleId` and title/body in the Intent (NotifyReceiver puts them in the PendingIntent), so once there’s only one alarm, rollover should keep user text.
-
----
-
-## Where Fixes Must Happen
-
-### Plugin (daily-notification-plugin)
-
-**1. Cancel prefetch (and related) WorkManager jobs when scheduling**
-
-- **File:** `DailyNotificationPlugin.kt` (or wherever `scheduleDailyNotification` is implemented).
-- **Change:** When handling `scheduleDailyNotification`, after `cleanupExistingNotificationSchedules` and before (or after) `ScheduleHelper.scheduleDailyNotification`, call a method that cancels all WorkManager work that can create a second alarm. Prefer reusing **ScheduleHelper.cancelAllWorkManagerJobs(context)** or adding a small helper that cancels only fetch-related tags (e.g. `daily_notification_fetch`, `prefetch`) so you don’t cancel display/dismiss work unnecessarily.
-- **Effect:** Pending prefetch jobs from older builds or previous flows will not run, so no new UUID alarm is created and no extra notification with fallback text.
-
-**2. (Already done) Do not enqueue prefetch for static reminders**
-
-- **ScheduleHelper.scheduleDailyNotification** already does **not** enqueue FetchWorker for static reminders. No change needed here; just ensure no other code path enqueues prefetch for the app’s single daily reminder.
-
-**3. (Optional) DailyNotificationFetchWorker: skip scheduling second alarm for static-reminder schedules**
-
-- If you ever enqueue prefetch with an explicit “static reminder” flag, in **DailyNotificationFetchWorker** inside `useFallbackContent` / `scheduleNotificationIfNeeded`, skip calling `scheduleNotificationIfNeeded` when that flag is set. For your current setup (no prefetch for static), this is redundant but makes the contract clear and future-proof.
-
-**4. Receiver: no DB on main thread**
-
-- Your **DailyNotificationReceiver** in the app’s plugin only reads Intent extras and enqueues work; it does not read Room on the main thread. If you still see `db_fallback_failed` in logcat, the failing DB access is elsewhere (e.g. another receiver or an old build). Ensure no BroadcastReceiver does Room/DB access on the main thread; resolve title/body in the Worker from `schedule_id` if Intent lacks them.
-
-### App (crowd-funder-for-time-pwa)
-
-**Scope: static reminders only.** For fixing static reminders, **no app code changes are required.** Real fetch-based content can be added later.
-
-**1. TimeSafariNativeFetcher**
-
-- **File:** `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`
-- **Current behavior:** Placeholder that returns `"TimeSafari Update"` / `"Check your starred projects for updates!"` (expected).
-- **For static reminders now:** Leave as-is. The plugin fix (cancel prefetch work when scheduling) ensures the only notification path is the static one; the fetcher is never used for display in that flow. No change needed.
-- **Later (optional):** When you implement real-world content fetching, replace the placeholder here so any future fetch-driven notifications show real content.
-
-**2. Build and dependency**
-
-- After plugin changes, ensure the app uses the updated plugin (point `package.json` at the fixed repo or publish and bump version), then **clean build** Android (`./gradlew clean`, rebuild, reinstall). Confirming the APK contains the plugin version that cancels prefetch work and does not enqueue prefetch for static reminders avoids stale behavior from old builds.
-
----
-
-## Verification After Fixes
-
-1. **Single notification, user text**
-   - Set daily reminder with a **distinct** title/body and a time 2–3 minutes ahead. Wait until that time.
-   - **Expect:** Exactly **one** notification at that time with your text. No second notification (no UUID, no “Daily Update” or “starred projects”).
-
-2. **No out-of-schedule notification**
-   - Change reminder time (e.g. from 21:53 to 21:56) and save. Wait past 21:53 and until 21:56.
-   - **Expect:** No notification at 21:53; one at 21:56 with your text.
-
-3. **Rollover**
-   - Let the correct notification fire once so rollover runs. Next day (or next occurrence) you should see **one** notification with the same user text.
-
-4. **Logcat**
-   - No `display=<uuid>` at the same time as `static_reminder id=daily_timesafari_reminder`.
-   - After scheduling (e.g. edit and save), you should see prefetch/fetch work being cancelled if you add a log in the cancel path.
-
----
-
-## Short Summary
-
-| Issue | Cause | Fix location |
-|-------|--------|--------------|
-| Extra notification at same or different time | Prefetch WorkManager job still runs and creates second (UUID) alarm via legacy scheduler; that alarm is never cancelled on reschedule | **Plugin:** Cancel fetch-related WorkManager jobs when `scheduleDailyNotification` is called |
-| Fallback text ("Daily Update" / "Good morning!") | FetchWorker’s `useFallbackContent` → `scheduleNotificationIfNeeded` creates alarm with that content | **Plugin:** Same as above (no prefetch run → no fallback alarm); optionally FetchWorker skips scheduling when static-reminder flag set |
-| "Starred projects" text | TimeSafariNativeFetcher placeholder used when a fetch path runs | **Plugin:** Same as above (no prefetch → no fetch path). **App:** No change for static reminders; leave fetcher as placeholder until real fetch is implemented. |
-| Wrong content on rollover | Rollover run keyed by UUID or notify_* and no title/body in Intent → Worker loads from Room by that id → wrong/empty content | **Plugin:** Avoid creating UUID/notify_* run (cancel prefetch). Static rollover already passes schedule_id and title/body. |
-
-The critical missing step is **cancelling prefetch (and fetch) WorkManager work when the user schedules or reschedules** the daily notification. That prevents any pending prefetch from running and creating the second alarm with fallback or “starred projects” text.
-
----
-
-## For Cursor (plugin repo) — actionable handoff
-
-Use this section when applying the fix in the **daily-notification-plugin** repo (e.g. with Cursor). Paste or @-mention this doc as context.
-
-**Goal:** For static reminders, only one notification at the user's chosen time with user-set title/body. No extra notification from pending prefetch (UUID alarm with fallback or "starred projects" text).
-
-**Root cause:** `scheduleDailyNotification` cleans up DB schedules and alarms but **does not cancel WorkManager prefetch jobs**. Any previously enqueued job (tag `daily_notification_fetch`) still runs, then creates a second alarm via `DailyNotificationScheduler` (UUID). That alarm is never cancelled on reschedule. Fix: cancel fetch-related WorkManager work when the user schedules.
-
-**Change (required):**
-
-1. **Cancel fetch-related WorkManager jobs when handling `scheduleDailyNotification`**
-   - **File:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`
-   - **Where:** In `scheduleDailyNotification(call)`, inside the `CoroutineScope(Dispatchers.IO).launch { ... }` block, **after** `ScheduleHelper.cleanupExistingNotificationSchedules(...)` and **before** `ScheduleHelper.scheduleDailyNotification(...)`.
-   - **What:** Call a method that cancels WorkManager work that can create a second alarm. Reuse **ScheduleHelper.cancelAllWorkManagerJobs(context)** (it already cancels `prefetch`, `daily_notification_fetch`, etc.). If you prefer not to cancel display/dismiss work, add a helper that only cancels `daily_notification_fetch` and `prefetch` and call that instead.
-   - **Example (using existing helper):**
-     ```kotlin
-     ScheduleHelper.cancelAllWorkManagerJobs(context)
-     ```
-     (If `cancelAllWorkManagerJobs` is suspend, call it with `runBlocking { }` or from the same coroutine scope.)
-
-**No other plugin changes needed for this fix:** ScheduleHelper already does not enqueue prefetch for static reminders; the only missing step is cancelling **pending** prefetch work when the user schedules or reschedules.
-
-**Files to look at (plugin Android):**
-- `DailyNotificationPlugin.kt` — `scheduleDailyNotification(call)` (add cancel call after cleanup, before ScheduleHelper.scheduleDailyNotification).
-- `ScheduleHelper` (in same file or separate) — `cancelAllWorkManagerJobs(context)` (already exists; ensure it cancels at least `daily_notification_fetch` and `prefetch`).

doc/GLOSSARY.md

@@ -0,0 +1,21 @@
+# Glossary
+
+**T (slot time)** — The local wall-clock time a notification should fire (e.g., 08:00).
+
+**T–lead** — The moment **`prefetchLeadMinutes`** before **T** when the system *attempts* a **single** background prefetch. T–lead **controls prefetch attempts, not arming**; locals are pre-armed earlier to guarantee closed-app delivery.
+
+**Rolling window** — Always keep **today's remaining** (and tomorrow if iOS pending caps allow) locals **armed** so the OS can deliver while the app is closed.
+
+**TTL (time-to-live)** — Maximum allowed payload age **at fire time**. If `T − fetchedAt > ttlSeconds`, we **skip** arming for that T.
+
+**Shared DB (default)** — The app and plugin open the **same SQLite file**; the app owns schema/migrations, the plugin performs short writes with WAL.
+
+**WAL (Write-Ahead Logging)** — SQLite journaling mode that permits concurrent reads during writes; recommended for foreground-read + background-write.
+
+**`PRAGMA user_version`** — An integer the app increments on each migration; the plugin **checks** (does not migrate) to ensure compatibility.
+
+**Exact alarm (Android)** — Minute-precise alarm via `AlarmManager.setExactAndAllowWhileIdle`, subject to policy and permission.
+
+**Windowed alarm (Android)** — Batched/inexact alarm via `setWindow(start,len)`; we target **±10 minutes** when exact alarms are unavailable.
+
+**Start-on-Login** — Electron feature that automatically launches the application when the user logs into their system, enabling background notification scheduling and delivery after system reboot.

doc/NOTIFICATION_TROUBLESHOOTING.md

@@ -1,82 +0,0 @@
-# TimeSafari — Daily notifications troubleshooting (iOS & Android)
-
-**Last updated:** 2026-03-06 17:08 PST  
-**Audience:** End-users  
-**Applies to:** TimeSafari iOS/Android native app (daily notifications scheduled on-device)
-
-If your **Daily Reminder** or notification doesn’t show up, follow the steps below.
-
-## Before you start
-
-- These notifications are **scheduled on your device** (no browser/web push).
-- If you previously followed an older “web notifications” guide, those steps no longer apply for iOS/Android builds.
-
-## 1) Check your in-app notification settings
-
-- Tap **Profile** in the bottom bar
-- Under **Notifications**, confirm:
-  - **Daily Reminder** is **enabled**
-  - The **time** is set correctly
-  - The message looks correct
-- If it’s already enabled, try to:
-  - Turn it **off**
-  - Turn it **on** again
-  - Re-set the time and message
-
-## 2) iOS troubleshooting
-
-### Allow notifications for TimeSafari
-
-1. Open **Settings** → **Notifications**
-2. Tap **TimeSafari**
-3. Turn **Allow Notifications** on
-4. Enable at least one delivery style (recommended):
-  - **Lock Screen**
-  - **Notification Center**
-  - **Banners**
-5. Optional but helpful:
-  - **Sounds** on (if you want an audible reminder)
-
-### Focus / Do Not Disturb
-
-If you’re using **Focus** or **Do Not Disturb**, notifications may be silenced or hidden.
-
-- Open **Settings** → **Focus**
-- Check the active Focus mode and ensure **TimeSafari** is allowed (or temporarily disable Focus to test)
-
-### After restarting your phone
-
-If you recently restarted iOS and don’t see the notification, open **TimeSafari** once. (You don’t need to change anything.)
-
-## 3) Android troubleshooting
-
-### Allow notifications for TimeSafari
-
-1. Open **Settings** → **Apps**
-2. Tap **TimeSafari** → **Manage notifications** (wording varies)
-3. Turn notifications **on**
-4. If Android shows notification categories/channels for the app, ensure the relevant channel is allowed.
-
-### Battery / background restrictions
-
-Battery optimization can delay or block scheduled notifications.
-
-- Open **Settings** → **Apps** → **TimeSafari** → **Battery usage** (wording varies)
-- If available:
-  - Set **Battery usage** to **Unrestricted**
-  - Turn **Allow background usage** on
-  - Disable optimization for TimeSafari
-- If your device has lists like **Sleeping apps** / **Restricted apps**, remove TimeSafari from them
-
-### After restarting your phone
-
-Depending on the device manufacturer, Android can clear scheduled notifications during a reboot. If you restarted recently:
-
-- Open **TimeSafari** once (you don’t need to change anything)
-
-## 4) If it still doesn’t work
-
-- Ensure you’re on the latest TimeSafari app version.
-- If you denied permission earlier, re-enable notifications in system settings (above).
-- As a last resort, uninstall/reinstall the app (you’ll need to enable notifications again and reconfigure the daily reminder). **Important:** Before uninstalling, back up your identifier seed so you can import it back later: **Profile → Data Management → Backup Identifier Seed**.
-

doc/PLUGIN_NOTIFICATION_FIX_ANDROID.md

@@ -1,129 +0,0 @@
-# Android plugin: New Activity notification when API has no activities
-
-**Audience:** Maintainers of `@timesafari/daily-notification-plugin` (Android / Kotlin).  
-**Host app:** TimeSafari (`crowd-funder-for-time-pwa`) — this file lives in the **app** repo only as a handoff; apply changes in the **plugin** repo.
-
-**Problem (product):** “New Activity” should notify only when the API reports new/updated activity. The host’s native fetcher (`TimeSafariNativeFetcher`) returns an **empty** `List<NotificationContent>` when the API’s `data` array is empty. Users still see a **daily** local notification.
-
-**Version note:** This diagnosis was first written against older plugin builds (e.g. **2.1.x / 2.2.x**). After upgrading the host to **`@timesafari/daily-notification-plugin` 3.0.0**, the Android files below were **re-read** from `node_modules`. The relevant logic is **unchanged** in 3.0.0: the same two mechanisms still explain unwanted daily notifications when the API returns no rows. If you maintain the plugin, re-verify after each major release.
-
-**Root cause (Android, confirmed in plugin v3.0.0 sources under `node_modules`):** Two mechanisms interact:
-
-1. **`FetchWorker.kt` — empty native fetch is converted to synthetic JSON instead of “skip”**  
-   When the dual prefetch runs with the native fetcher and the list is empty, `notificationContentsToDualPayloadBytes` **replaces** the empty list with a JSON payload `"No updates"` / `"No new content"`, and the work unit still completes successfully. The dual path then **always** arms the chained notify alarm when `isDual && nextNotifyAt > 0L` — so a notification is still scheduled for the notify window.
-
-   Reference (plugin):
-
-   ```kotlin
-   // FetchWorker.kt — notificationContentsToDualPayloadBytes (~371–374 in v3.0.0)
-   if (contents.isEmpty()) {
-       return """{"title":"No updates","body":"No new content"}""".toByteArray(Charsets.UTF_8)
-   }
-   ```
-
-   ```kotlin
-   // FetchWorker.kt — doWork(), tail of success path (~306–309 in v3.0.0)
-   if (isDual && nextNotifyAt > 0L) {
-       DualScheduleNotifyScheduler.scheduleChainedNotifyAlarm(applicationContext, nextNotifyAt)
-       DualScheduleFetchRecovery.enqueueFromPersistedConfig(applicationContext)
-   }
-   ```
-
-2. **`DualScheduleHelper.kt` — `fallbackBehavior: "show_default"` uses `userNotification` defaults**  
-   At display time, if there is **no** fresh dual-scope cache within `relationship.contentTimeout`, the helper falls back to the **persisted** `userNotification.title` / `userNotification.body` when `fallbackBehavior` is `"show_default"`. The host app sets those defaults to copy such as “New Activity” / “Check your starred projects…”, so the user sees that **even when the API had nothing**, if the cache path doesn’t supply something else.
-
-   Reference (plugin):
-
-   ```kotlin
-   // DualScheduleHelper.kt — resolveDualContentBlocking (simplified; ~31–57 in v3.0.0)
-   val fallbackBehavior = relationship?.optString("fallbackBehavior", "show_default") ?: "show_default"
-   val defaultTitle = userNotification.optString("title", "Daily Notification")
-   val defaultBody = userNotification.optString("body", "Your daily update is ready")
-   // ...
-   } else {
-       if (fallbackBehavior != "show_default") return null
-       Pair(defaultTitle, defaultBody)
-   }
-   ```
-
-**TypeScript contract (plugin `src/definitions.ts` in v3.0.0 — `DualScheduleConfiguration.relationship`):**
-
-```ts
-relationship?: {
-  autoLink: boolean;
-  contentTimeout: number;
-  fallbackBehavior: 'skip' | 'show_default' | 'retry';
-};
-```
-
-`skip` is only partially useful on Android **with the current fetch implementation**: it avoids the **default title/body** branch in `DualScheduleHelper` when cache is missing/stale, but it does **not** by itself stop a notification if the fetch path still materializes content (including the synthetic `"No updates"` payload) or if chained notify is already armed.
-
-**3.0.0 vs 2.2.x:** Plugin **3.0.0** advertises broader features (e.g. TTL-at-fire, observability). Those do **not** replace the dual-fetch pipeline inspected here: `FetchWorker` still maps an empty native list to JSON and still schedules the chained notify on success; `DualScheduleHelper` still applies `show_default` vs defaults when cache is absent or outside `contentTimeout`. Revisit this doc if a future release changes `notificationContentsToDualPayloadBytes` or the dual notify gate.
-
----
-
-## Recommended plugin changes (Android)
-
-### 1) Treat empty native fetch as “no notification” (primary)
-
-**File:** `android/src/main/java/org/timesafari/dailynotification/FetchWorker.kt`
-
-**Issue:** `notificationContentsToDualPayloadBytes` must not turn an empty list into a non-empty payload if the product contract is “no rows in API → no notification.”
-
-**Direction:**
-
-- **Before:** Empty list → JSON `No updates` / `No new content` → success → chained notify scheduled.
-- **After (one of):**
-  - **A)** Return a dedicated sentinel payload (e.g. `{ "skipNotification": true }`) and teach **`NotifyReceiver` / worker** that resolves dual content to **not post** when that sentinel is present; **or**
-  - **B)** On empty list, **do not** call `DualScheduleNotifyScheduler.scheduleChainedNotifyAlarm` for this cycle (and optionally persist “last fetch had no content” for the helper); **or**
-  - **C)** Store an empty/marker cache row that `DualScheduleHelper.resolveDualContentBlocking` interprets as “return null” (no notification).
-
-Pick one strategy and keep behavior consistent with `relationship.fallbackBehavior`:
-
-- If `fallbackBehavior == "skip"`: skip notification when fetch returns empty or when sentinel indicates skip.
-- If `fallbackBehavior == "show_default"`: keep current default-title/body behavior **only** when the product intends it (may be wrong for TimeSafari).
-
-### 2) Honor `relationship.fallbackBehavior` end-to-end
-
-**Files:** `FetchWorker.kt`, `DualScheduleHelper.kt`, any worker/receiver that posts the dual notification.
-
-**Issue:** `DualScheduleHelper` reads `fallbackBehavior`, but the fetch path does not use the same semantics for “empty API result.”
-
-**Direction:** When persisting dual config, pass `fallbackBehavior` into the fetch success path so that **empty fetch + `skip`** never schedules or displays a notification.
-
-### 3) Tests
-
-- Dual fetch + native fetcher returns **empty list** → **no** notification posted (or no chained alarm), matching host expectation.
-- Non-empty list → notification with fetcher-provided title/body.
-- Optional: `fallbackBehavior` matrix (`skip` / `show_default`) with stale cache vs fresh cache.
-
----
-
-## Host app follow-up (separate PR in `crowd-funder-for-time-pwa`)
-
-After the plugin implements empty-fetch semantics, set in `buildDualScheduleConfig` (`src/services/notifications/dualScheduleConfig.ts`):
-
-```ts
-relationship: {
-  autoLink: true,
-  contentTimeout: 5 * 60 * 1000,
-  fallbackBehavior: "skip", // was "show_default"
-},
-```
-
-Only do this once Android behavior matches the contract (otherwise users may get **no** notification even when you would want defaults on network failure — product decision).
-
----
-
-## References in this repo (context only)
-
-- Host native fetcher returns no content when API `data` is empty: `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` (`parseApiResponse`).
-- Host dual config today uses `fallbackBehavior: "show_default"`: `src/services/notifications/dualScheduleConfig.ts`.
-
----
-
-## Plugin version verification
-
-- **Last verified against:** `@timesafari/daily-notification-plugin` **3.0.0** (`node_modules/.../package.json`).
-- **Prior builds:** Behavior matched the earlier **2.1.x** analysis; **2.2.0 → 3.0.0** did not remove the empty-list → synthetic JSON mapping or the chained-notify success path in the inspected sources.
-- Re-verify line numbers after rebasing or patching the plugin repo.

doc/README-BUILD-GUARD.md

@@ -330,6 +330,7 @@ Track the effectiveness of your Build Architecture Guard:
 ## 📝 **Changelog**
 
 ### 2025-08-22 - Shell Compatibility Fix
+
 - **Fixed**: Replaced `mapfile` command with portable alternative for cross-shell compatibility
 - **Impact**: Resolves "mapfile: command not found" errors in pre-commit hooks
 - **Files**: `scripts/build-arch-guard.sh`

doc/README.md

@@ -1,77 +1,11 @@
-# TimeSafari Docs
+# TimeSafari — Native-First Notification System (Clean Pack) — 2025-09-07
 
-## Generating PDF from Markdown on OSx
+This pack contains a single-version **Native-First** documentation set with a clear definition of **T–lead** and aligned terminology.
 
-This uses Pandoc and BasicTex (LaTeX) Installed through Homebrew.
+**Native-First =** OS-scheduled **background prefetch at T–lead** + **pre-armed one-shot local notifications**. Web-push is retired.
 
-### Set Up
+**Included files**
 
-```bash
-brew install pandoc
-
-brew install basictex
-
-# Setting up LaTex packages
-
-# First update tlmgr
-sudo tlmgr update --self
-
-# Then install LaTex packages
-sudo tlmgr install bbding
-sudo tlmgr install enumitem
-sudo tlmgr install environ
-sudo tlmgr install fancyhdr
-sudo tlmgr install framed
-sudo tlmgr install import
-sudo tlmgr install lastpage  # Enables Page X of Y
-sudo tlmgr install mdframed
-sudo tlmgr install multirow
-sudo tlmgr install needspace
-sudo tlmgr install ntheorem
-sudo tlmgr install tabu
-sudo tlmgr install tcolorbox
-sudo tlmgr install textpos
-sudo tlmgr install titlesec
-sudo tlmgr install titling  # Required for the fancy headers used
-sudo tlmgr install threeparttable
-sudo tlmgr install trimspaces
-sudo tlmgr install tocloft  # Required for \tableofcontents generation
-sudo tlmgr install varwidth
-sudo tlmgr install wrapfig
-
-# Install fonts
-sudo tlmgr install cmbright
-sudo tlmgr install collection-fontsrecommended # And set up fonts
-sudo tlmgr install fira
-sudo tlmgr install fontaxes
-sudo tlmgr install libertine # The main font the doc uses
-sudo tlmgr install opensans
-sudo tlmgr install sourceserifpro
-
-```
-
-#### References
-
-The following guide was adapted to this project except that we install with Brew and have a few more packages.
-
-Guide: <https://daniel.feldroy.com/posts/setting-up-latex-on-mac-os-x>
-
-### Usage
-
-Use the `pandoc` command to generate a PDF.
-
-```bash
-pandoc usage-guide.md -o usage-guide.pdf 
-```
-
-And you can open the PDF with the `open` command.
-
-```bash
-open usage-guide.pdf
-```
-
-Or use this one-liner
-
-```bash
-pandoc usage-guide.md -o usage-guide.pdf && open usage-guide.pdf
-```
+- `notification-system.md` (merged comprehensive guide)
+- `web-push-cleanup-guide.md` (cleanup instructions)
+- `GLOSSARY.md` (definitions incl. **T** and **T–lead**)

doc/WORKER_ONLY_DATABASE_IMPLEMENTATION.md

@@ -117,25 +117,25 @@ async function getDatabaseService() {
 
 ## Files Modified
 
-1. **src/interfaces/worker-messages.ts** *(NEW)*
+1. **src/interfaces/worker-messages.ts** _(NEW)_
    - Type definitions for worker communication
    - Request and response message interfaces
 
-2. **src/registerSQLWorker.js** *(MAJOR REWRITE)*
+2. **src/registerSQLWorker.js** _(MAJOR REWRITE)_
    - Message-based operation handling
    - **Fixed circular dependency with lazy loading**
    - Proper error handling and response formatting
 
-3. **src/services/platforms/WebPlatformService.ts** *(MAJOR REWRITE)*
+3. **src/services/platforms/WebPlatformService.ts** _(MAJOR REWRITE)_
    - Worker-only database access
    - Message sending and response handling
    - Timeout and error management
 
-4. **src/main.web.ts** *(SIMPLIFIED)*
+4. **src/main.web.ts** _(SIMPLIFIED)_
    - Removed duplicate worker creation
    - Simplified initialization flow
 
-5. **WORKER_ONLY_DATABASE_IMPLEMENTATION.md** *(NEW)*
+5. **WORKER_ONLY_DATABASE_IMPLEMENTATION.md** _(NEW)_
    - Complete documentation of changes
 
 ## Benefits

doc/android-api-23-upgrade-impact-analysis.md

@@ -1,259 +0,0 @@
-# Android API 23 Upgrade Impact Analysis
-
-**Date:** 2025-12-03  
-**Current minSdkVersion:** 22 (Android 5.1 Lollipop)  
-**Proposed minSdkVersion:** 23 (Android 6.0 Marshmallow)  
-**Impact Assessment:** Low to Moderate
-
-## Executive Summary
-
-Upgrading from API 22 to API 23 will have **minimal code impact** but may affect device compatibility. The main change is that API 23 introduced runtime permissions, but since the app uses Capacitor plugins which handle permissions, the impact is minimal.
-
-## Code Impact Analysis
-
-### ✅ No Breaking Changes in Existing Code
-
-#### 1. API Level Checks in Code
-All existing API level checks are for **much higher APIs** than 23, so they won't be affected:
-
-**MainActivity.java:**
-- `Build.VERSION_CODES.R` (API 30+) - Edge-to-edge display
-- `Build.VERSION_CODES.TIRAMISU` (API 33+) - Intent extras handling
-- Legacy path (API 21-29) - Will still work, but API 22 devices won't be supported
-
-**SafeAreaPlugin.java:**
-- `Build.VERSION_CODES.R` (API 30+) - Safe area insets
-
-**Conclusion:** No code changes needed for API level checks.
-
-#### 2. Permissions Handling
-
-**Current Permissions in AndroidManifest.xml:**
-- `INTERNET` - Normal permission (no runtime needed)
-- `READ_EXTERNAL_STORAGE` - Dangerous permission (runtime required on API 23+)
-- `WRITE_EXTERNAL_STORAGE` - Dangerous permission (runtime required on API 23+)
-- `CAMERA` - Dangerous permission (runtime required on API 23+)
-
-**Current Implementation:**
-- ✅ App uses **Capacitor plugins** for camera and file access
-- ✅ Capacitor plugins **already handle runtime permissions** automatically
-- ✅ No manual permission request code found in the codebase
-- ✅ QR Scanner uses Capacitor's BarcodeScanner plugin which handles permissions
-
-**Conclusion:** No code changes needed - Capacitor handles runtime permissions automatically.
-
-#### 3. Dependencies Compatibility
-
-**AndroidX Libraries:**
-- `androidx.appcompat:appcompat:1.6.1` - ✅ Supports API 23+
-- `androidx.core:core:1.12.0` - ✅ Supports API 23+
-- `androidx.fragment:fragment:1.6.2` - ✅ Supports API 23+
-- `androidx.coordinatorlayout:coordinatorlayout:1.2.0` - ✅ Supports API 23+
-- `androidx.core:core-splashscreen:1.0.1` - ✅ Supports API 23+
-
-**Capacitor Plugins:**
-- `@capacitor/core:6.2.0` - ✅ Requires API 23+ (official requirement)
-- `@capacitor/camera:6.0.0` - ✅ Handles runtime permissions
-- `@capacitor/filesystem:6.0.0` - ✅ Handles runtime permissions
-- `@capacitor-community/sqlite:6.0.2` - ✅ Supports API 23+
-- `@capacitor-mlkit/barcode-scanning:6.0.0` - ✅ Supports API 23+
-
-**Third-Party Libraries:**
-- No Firebase or other libraries with API 22-specific requirements found
-- All dependencies appear compatible with API 23+
-
-**Conclusion:** All dependencies are compatible with API 23.
-
-#### 4. Build Configuration
-
-**Current Configuration:**
-- `compileSdkVersion = 36` (Android 14)
-- `targetSdkVersion = 36` (Android 14)
-- `minSdkVersion = 22` (Android 5.1) ← **Only this needs to change**
-
-**Required Change:**
-```gradle
-// android/variables.gradle
-ext {
-    minSdkVersion = 23  // Change from 22 to 23
-    // ... rest stays the same
-}
-```
-
-**Conclusion:** Only one line needs to be changed.
-
-## Device Compatibility Impact
-
-### Device Coverage Loss
-
-**API 22 (Android 5.1 Lollipop):**
-- Released: March 2015
-- Market share: ~0.1% of active devices (as of 2024)
-- Devices affected: Very old devices from 2015-2016
-
-**API 23 (Android 6.0 Marshmallow):**
-- Released: October 2015
-- Market share: ~0.3% of active devices (as of 2024)
-- Still very low, but slightly higher than API 22
-
-**Impact:** Losing support for ~0.1% of devices (essentially negligible)
-
-### User Base Impact
-
-**Recommendation:** Check your analytics to see actual usage:
-- If you have analytics, check percentage of users on API 22
-- If < 0.5%, upgrade is safe
-- If > 1%, consider the business impact
-
-## Runtime Permissions (API 23 Feature)
-
-### What Changed in API 23
-
-**Before API 23 (API 22 and below):**
-- Permissions granted at install time
-- User sees all permissions during installation
-- No runtime permission dialogs
-
-**API 23+ (Runtime Permissions):**
-- Dangerous permissions must be requested at runtime
-- User sees permission dialogs when app needs them
-- Better user experience and privacy
-
-### Current App Status
-
-**✅ Already Compatible:**
-- App uses Capacitor plugins which **automatically handle runtime permissions**
-- Camera plugin requests permissions when needed
-- Filesystem plugin requests permissions when needed
-- No manual permission code needed
-
-**Conclusion:** App is already designed for runtime permissions via Capacitor.
-
-## Potential Issues to Watch
-
-### 1. APK Size
-- Some developers report APK size increases after raising minSdkVersion
-- **Action:** Monitor APK size after upgrade
-- **Expected Impact:** Minimal (API 22 → 23 is a small jump)
-
-### 2. Testing Requirements
-- Need to test on API 23+ devices
-- **Action:** Test on Android 6.0+ devices/emulators
-- **Current:** App likely already tested on API 23+ devices
-
-### 3. Legacy Code Path
-- MainActivity has legacy code for API 21-29
-- **Impact:** This code will still work, but API 22 devices won't be supported
-- **Action:** No code changes needed, but legacy path becomes API 23-29
-
-### 4. Capacitor Compatibility
-- Capacitor 6.2.0 officially requires API 23+
-- **Current Situation:** App runs on API 22 (may be working due to leniency)
-- **After Upgrade:** Officially compliant with Capacitor requirements
-- **Benefit:** Better compatibility guarantees
-
-## Files That Need Changes
-
-### 1. Build Configuration
-**File:** `android/variables.gradle`
-```gradle
-ext {
-    minSdkVersion = 23  // Change from 22
-    // ... rest unchanged
-}
-```
-
-### 2. Documentation
-**Files to Update:**
-- `doc/shared-image-plugin-implementation-plan.md` - Update version notes
-- Any README files mentioning API 22
-- Build documentation
-
-### 3. No Code Changes Required
-- ✅ No Java/Kotlin code changes needed
-- ✅ No AndroidManifest.xml changes needed
-- ✅ No permission handling code changes needed
-
-## Testing Checklist
-
-After upgrading to API 23, test:
-
-- [ ] App builds successfully
-- [ ] App installs on API 23 device/emulator
-- [ ] Camera functionality works (permissions requested)
-- [ ] File access works (permissions requested)
-- [ ] Share functionality works
-- [ ] QR code scanning works
-- [ ] Deep linking works
-- [ ] All Capacitor plugins work correctly
-- [ ] No crashes or permission-related errors
-- [ ] APK size is acceptable
-
-## Rollback Plan
-
-If issues arise:
-
-1. Revert `android/variables.gradle` to `minSdkVersion = 22`
-2. Rebuild and test
-3. Document issues encountered
-4. Address issues before retrying upgrade
-
-## Recommendation
-
-### ✅ **Proceed with Upgrade**
-
-**Reasons:**
-1. **Minimal Code Impact:** Only one line needs to change
-2. **Already Compatible:** App uses Capacitor which handles runtime permissions
-3. **Device Impact:** Negligible (~0.1% of devices)
-4. **Capacitor Compliance:** Officially meets Capacitor 6 requirements
-5. **Future-Proofing:** Better alignment with modern Android development
-
-**Timeline:**
-- **Low Risk:** Can be done anytime
-- **Recommended:** Before implementing SharedImagePlugin (cleaner baseline)
-- **Testing:** 1-2 hours of testing on API 23+ devices
-
-## Migration Steps
-
-1. **Update Build Configuration:**
-   ```bash
-   # Edit android/variables.gradle
-   minSdkVersion = 23
-   ```
-
-2. **Sync Gradle:**
-   ```bash
-   cd android
-   ./gradlew clean
-   ```
-
-3. **Build and Test:**
-   ```bash
-   npm run build:android:test
-   # Test on API 23+ device/emulator
-   ```
-
-4. **Verify Permissions:**
-   - Test camera access
-   - Test file access
-   - Verify permission dialogs appear
-
-5. **Update Documentation:**
-   - Update any docs mentioning API 22
-   - Update implementation plan
-
-## Summary
-
-| Aspect | Impact | Status |
-|--------|--------|--------|
-| **Code Changes** | None required | ✅ Safe |
-| **Dependencies** | All compatible | ✅ Safe |
-| **Permissions** | Already handled | ✅ Safe |
-| **Device Coverage** | ~0.1% loss | ⚠️ Minimal |
-| **Build Config** | 1 line change | ✅ Simple |
-| **Testing** | Standard testing | ✅ Required |
-| **Risk Level** | Low | ✅ Low Risk |
-
-**Final Recommendation:** Proceed with upgrade. The benefits (Capacitor compliance, future-proofing) outweigh the minimal risks (negligible device loss, no code changes needed).
-

doc/android-asset-validation.md

@@ -11,12 +11,14 @@ The Android Asset Validation System automatically detects and fixes missing Andr
 ## Problem Solved
 
 Previously, Android builds would fail with errors like:
+
 ```
 error: resource drawable/splash (aka app.timesafari.app:drawable/splash) not found.
 error: resource mipmap/ic_launcher (aka app.timesafari.app:mipmap/ic_launcher) not found.
 ```
 
 This happened when:
+
 - Source assets existed but weren't generated into Android resources
 - Android resource directories were missing
 - Asset generation tools weren't run before building
@@ -45,16 +47,19 @@ npm run build:android:studio
 ### What Gets Validated
 
 #### Source Assets (Required)
+
 - `resources/icon.png` - App icon source
 - `resources/splash.png` - Splash screen source  
 - `resources/splash_dark.png` - Dark mode splash source
 
 #### Android Resources (Generated)
+
 - `android/app/src/main/res/drawable/splash.png` - Splash screen drawable
 - `android/app/src/main/res/mipmap-*/ic_launcher.png` - App icons for all densities
 - `android/app/src/main/res/mipmap-*/ic_launcher_round.png` - Round app icons for all densities
 
 ### Density Levels Checked
+
 - `mipmap-mdpi` (1x)
 - `mipmap-hdpi` (1.5x)  
 - `mipmap-xhdpi` (2x)
@@ -64,6 +69,7 @@ npm run build:android:studio
 ## Usage
 
 ### Automatic Validation (Recommended)
+
 The validation runs automatically during all Android builds:
 
 ```bash
@@ -78,6 +84,7 @@ npm run build:android:debug
 ```
 
 ### Manual Validation
+
 Run validation only to check/fix assets:
 
 ```bash
@@ -89,6 +96,7 @@ npm run assets:validate:android
 ```
 
 ### Validation Only (No Regeneration)
+
 Check configuration without fixing:
 
 ```bash
@@ -98,6 +106,7 @@ npm run assets:validate
 ## Error Handling
 
 ### Missing Source Assets
+
 If source assets are missing, the build fails with clear error messages:
 
 ```
@@ -108,6 +117,7 @@ If source assets are missing, the build fails with clear error messages:
 ```
 
 ### Missing Generated Resources
+
 If generated resources are missing, they're automatically regenerated:
 
 ```
@@ -119,6 +129,7 @@ If generated resources are missing, they're automatically regenerated:
 ```
 
 ### Generation Failure
+
 If regeneration fails, helpful guidance is provided:
 
 ```
@@ -131,6 +142,7 @@ If regeneration fails, helpful guidance is provided:
 ## Integration Points
 
 ### Build Script Integration
+
 The validation is integrated into the main build process:
 
 ```bash
@@ -143,6 +155,7 @@ validate_android_assets || {
 ```
 
 ### NPM Scripts
+
 New npm scripts for asset management:
 
 ```json
@@ -156,17 +169,20 @@ New npm scripts for asset management:
 ## Benefits
 
 ### For Developers
+
 - **No More Build Failures**: Automatic detection and fixing of missing resources
 - **Faster Development**: No need to manually run asset generation tools
 - **Clear Error Messages**: Helpful guidance when issues occur
 - **Consistent Results**: Same validation on all development machines
 
 ### For CI/CD
+
 - **Reliable Builds**: Consistent asset validation across environments
 - **Early Detection**: Catches issues before they reach production
 - **Automated Fixes**: Self-healing builds when possible
 
 ### For Project Maintenance
+
 - **Reduced Support**: Fewer "build doesn't work" issues
 - **Documentation**: Clear requirements for required assets
 - **Standardization**: Consistent asset structure across the project
@@ -176,21 +192,27 @@ New npm scripts for asset management:
 ### Common Issues
 
 #### "No assets found in the asset path"
+
 This occurs when the `assets/` directory is empty. The validation system automatically copies source assets and regenerates them.
 
 #### "Failed to generate Android assets"
+
 Check that:
+
 - Source assets exist in `resources/`
 - `@capacitor/assets` is installed
 - You have write permissions to the Android directories
 
 #### "Asset generation completed but some resources are still missing"
+
 This indicates a problem with the asset generation tool. Try:
+
 1. Running `npm install` to ensure dependencies are up to date
 2. Manually running `npx @capacitor/assets generate`
 3. Checking the asset generation logs for specific errors
 
 ### Manual Recovery
+
 If automatic regeneration fails, you can manually create the missing resources:
 
 ```bash
@@ -213,12 +235,14 @@ rm assets/icon.png assets/splash.png assets/splash_dark.png
 ## Future Enhancements
 
 ### Planned Improvements
+
 - **iOS Asset Validation**: Extend validation to iOS assets
 - **Asset Quality Checks**: Validate image dimensions and formats
 - **Performance Optimization**: Cache validation results
 - **CI/CD Integration**: Add validation to GitHub Actions
 
 ### Configuration Options
+
 - **Custom Asset Paths**: Support for different asset directory structures
 - **Validation Rules**: Configurable validation requirements
 - **Skip Options**: Ability to skip validation for specific scenarios

doc/android-daily-notification-second-schedule-issue.md

@@ -1,85 +0,0 @@
-# Android: Second notification doesn't fire (investigation & plan)
-
-**Handoff to plugin repo:** This doc can be used as context in the daily-notification-plugin repo (e.g. in Cursor) to fix the Android re-schedule issue. See **Plugin-side: where to look and what to try** and **Could "re-scheduling too soon" cause the failure?** for actionable plugin changes.
-
----
-
-## Current state
-
-- **Symptom**: After a fresh install, the first scheduled daily notification fires. When the user sets another notification (same or different time), it does not fire until the app is uninstalled and reinstalled.
-- **Test app**: The plugin's test app (`daily-notification-test`) does not show this issue; scheduling a second notification works.
-- **Attempted fix**: We changed the reminder ID from `timesafari_daily_reminder` to `daily_timesafari_reminder` so the plugin's rollover logic preserves the schedule ID (IDs starting with `daily_` are preserved). That did not fix the issue.
-
-## Could "re-scheduling too soon" cause the failure?
-
-**Yes, timing can matter.** The plugin is not very forgiving on Android in one case:
-
-- **Idempotence in `NotifyReceiver.scheduleExactNotification`**: Before scheduling, the plugin checks for an existing PendingIntent (same `scheduleId` or same trigger time). If one exists, it **skips** scheduling to avoid duplicates.
-- **After cancel**: When you re-schedule, the flow is `cancelNotification(scheduleId)` then `scheduleExactNotification(...)`. Android may not remove a cancelled PendingIntent from its cache immediately. If the idempotence check runs right after cancel, it can still see the old PendingIntent and treat the new schedule as a duplicate, so the second schedule is skipped.
-- **After the first notification fires**: The alarm is gone but the PendingIntent might still be in the system. If the user opens the app and re-schedules within a few seconds, the same “duplicate” logic can trigger.
-
-**Practical check:** Try waiting **5–10 seconds** after the first notification fires (or after changing time and saving) before saving again. If re-scheduling works when you wait but fails when you do it immediately, the cause is this timing/idempotence behavior. Fix would be in the plugin (e.g. short delay after cancel before idempotence check, or re-check after cancel).
-
-**Other timing in the plugin (do not apply to your flow):** `DailyNotificationScheduler` has a 10s “notification throttle” and a 30s “activeDid changed” grace; those are used only when scheduling from **fetched content / rollover**, not when the user calls `scheduleDailyNotification`. Your re-schedule path goes through `NotifyReceiver.scheduleExactNotification` only, so those timeouts are not the cause.
-
-## Differences: Test app vs TimeSafari
-
-| Aspect | Test app | TimeSafari (before alignment) |
-|--------|----------|-------------------------------|
-| **Method** | `scheduleDailyNotification(options)` | `scheduleDailyReminder(options)` |
-| **Options** | `{ time, title, body, sound, priority }` — **no `id`** | `{ id, time, title, body, repeatDaily, sound, vibration, priority }` |
-| **Effective scheduleId** | Plugin default: `"daily_notification"` | Explicit: `"daily_timesafari_reminder"` (then `"daily_timesafari_reminder"` after prefix fix) |
-| **Pre-cancel** | None | Calls `cancelDailyReminder({ reminderId })` before scheduling |
-| **Android cancelDailyReminder** | Not used | Plugin **does not expose** `cancelDailyReminder` on Android (only `cancelAllNotifications`). So the pre-cancel is a no-op or fails silently. |
-
-The plugin's `scheduleDailyNotification` flow already cancels the existing alarm for the **same** scheduleId via `NotifyReceiver.cancelNotification(context, scheduleId)` before scheduling. So the only behavioral difference that might matter is **which scheduleId is used** and **whether we pass an `id`**.
-
-## Plan (app-side only)
-
-1. **Platform-specific behavior** (implemented):
-   - **Android**: Use **`scheduleDailyNotification`** without passing `id` so the plugin uses default scheduleId **`"daily_notification"`**. Use **`reminderId = "daily_notification"`** for cancel/getStatus. **Do not** call `cancelDailyReminder` before scheduling on Android (test app does not; plugin cancels the previous alarm internally).
-   - **iOS**: Use **`scheduleDailyNotification`** with **`id: "daily_timesafari_reminder"`** and call **`cancelDailyReminder`** before scheduling so the reminder is removed from the notification center before rescheduling.
-2. **If Android re-schedule still fails**, next step is **plugin-side investigation** in the plugin repo (no patch in this repo):
-   - Add logging in `NotifyReceiver.scheduleExactNotification` (idempotence checks, PendingIntent/DB) and in `ScheduleHelper.scheduleDailyNotification` / `cleanupExistingNotificationSchedules`; compare logcat for test app vs TimeSafari when scheduling twice.
-   - Optionally in test app: pass an explicit `id` when scheduling and test scheduling twice; if it then fails, the bug is tied to custom scheduleIds and the fix belongs in the plugin.
-   - Confirm whether the second schedule is skipped by an idempotence check (e.g. PendingIntent still present, or DB `nextRunAt` within 1 min of new trigger) or by another code path.
-
-## Plugin-side: where to look and what to try
-
-*(Use this section when working in the daily-notification-plugin repo.)*
-
-**Entry point (user schedule):**  
-`DailyNotificationPlugin.kt` → `scheduleDailyNotification` → `ScheduleHelper.scheduleDailyNotification` → `NotifyReceiver.cancelNotification(context, scheduleId)` then `NotifyReceiver.scheduleExactNotification(...)`.
-
-**Relevant plugin files (paths relative to plugin root):**
-
-- **`android/.../NotifyReceiver.kt`**
-  - `scheduleExactNotification`: idempotence checks at start (PendingIntent by requestCode, by trigger time, then DB by scheduleId + nextRunAt within 60s). If any check finds an existing schedule, the function returns without scheduling.
-  - `cancelNotification`: cancels alarm and `existingPendingIntent.cancel()`. Android may not drop the PendingIntent from its cache immediately.
-- **`android/.../DailyNotificationPlugin.kt`** (or ScheduleHelper companion/object)
-  - `ScheduleHelper.scheduleDailyNotification`: calls `NotifyReceiver.cancelNotification(context, scheduleId)` then `NotifyReceiver.scheduleExactNotification(...)`.
-  - `cleanupExistingNotificationSchedules`: cancels and deletes other schedules; excludes current scheduleId.
-
-**Likely cause:** Idempotence in `scheduleExactNotification` runs *after* `cancelNotification` in the same flow. A just-cancelled PendingIntent can still be returned by `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)` and cause the new schedule to be skipped.
-
-**Suggested fixes (in plugin):**
-
-1. **Re-check after cancel:** In the path that does cancel-then-schedule (e.g. in `ScheduleHelper.scheduleDailyNotification`), after `cancelNotification(scheduleId)` either:
-   - Call `PendingIntent.getBroadcast(..., FLAG_NO_CREATE)` for that scheduleId in a short loop with a small delay (e.g. 50–100 ms) until it returns null, with a timeout (e.g. 500 ms), then call `scheduleExactNotification`; or
-   - Pass a flag into `scheduleExactNotification` to skip or relax the "existing PendingIntent" idempotence when the caller has just cancelled this scheduleId.
-2. **Or brief delay before idempotence:** When the schedule path has just called `cancelNotification(scheduleId)`, have `scheduleExactNotification` skip the PendingIntent check for that scheduleId if last cancel was < 1–2 s ago (e.g. store "justCancelled(scheduleId)" with timestamp).
-3. **Logging:** In `NotifyReceiver.scheduleExactNotification`, log when scheduling is skipped and which check triggered (PendingIntent by requestCode, by time, or DB). Capture logcat for "schedule, then fire, then re-schedule within a few seconds" to confirm.
-
-**Reproduce in test app:** In `daily-notification-test`, schedule once, let it fire (or wait), then schedule again within 1–2 seconds. If the second schedule doesn't fire, the bug is reproducible in the plugin; then apply one of the fixes above and re-test.
-
----
-
-## If changes are needed in the plugin repo (TimeSafari app note)
-
-Do **not** add a patch in this (TimeSafari) repo. Instead:
-
-1. **Reproduce in the plugin's test app** (e.g. pass an explicit `id` like `"custom_id"` when scheduling and try scheduling twice) to see if the issue is tied to custom scheduleIds.
-2. **Add the logging** above in the plugin's Android code and capture logs for “first schedule → fire → second schedule” in both test app and TimeSafari.
-3. **Fix in the plugin** (e.g. relax or correct idempotence, or ensure cancel + DB state are consistent for the same scheduleId) and release a new plugin version; then bump the plugin dependency in this app.
-
-No patch file or copy of plugin code is needed in the TimeSafari repo.

doc/android-emulator-deployment-guide.md

@@ -1,655 +0,0 @@
-# Android Emulator Deployment Guide (No Android Studio)
-
-**Author**: Matthew Raymer  
-**Date**: 2025-01-27  
-**Status**: 🎯 **ACTIVE** - Complete guide for deploying TimeSafari to Android emulator using command-line tools
-
-## Overview
-
-This guide provides comprehensive instructions for building and deploying TimeSafari to Android emulators using only command-line tools, without requiring Android Studio. It leverages the existing build system and adds emulator-specific deployment workflows.
-
-## Prerequisites
-
-### Required Tools
-
-1. **Android SDK Command Line Tools**
-   ```bash
-   # Install via package manager (Arch Linux)
-   sudo pacman -S android-sdk-cmdline-tools-latest
-   
-   # Or download from Google
-   # https://developer.android.com/studio/command-line
-   ```
-
-2. **Android SDK Platform Tools**
-   ```bash
-   # Install via package manager
-   sudo pacman -S android-sdk-platform-tools
-   
-   # Or via Android SDK Manager
-   sdkmanager "platform-tools"
-   ```
-
-3. **Android SDK Build Tools**
-   ```bash
-   sdkmanager "build-tools;34.0.0"
-   ```
-
-4. **Android Platform**
-   ```bash
-   sdkmanager "platforms;android-34"
-   ```
-
-5. **Android Emulator**
-   ```bash
-   sdkmanager "emulator"
-   ```
-
-6. **System Images**
-   ```bash
-   # For API 34 (Android 14)
-   sdkmanager "system-images;android-34;google_apis;x86_64"
-   
-   # For API 33 (Android 13) - alternative
-   sdkmanager "system-images;android-33;google_apis;x86_64"
-   ```
-
-### Environment Setup
-
-```bash
-# Add to ~/.bashrc or ~/.zshrc
-export ANDROID_HOME=$HOME/Android/Sdk
-export ANDROID_AVD_HOME=$HOME/.android/avd  # Important for AVD location
-export PATH=$PATH:$ANDROID_HOME/emulator
-export PATH=$PATH:$ANDROID_HOME/platform-tools
-export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
-export PATH=$PATH:$ANDROID_HOME/build-tools/34.0.0
-
-# Reload shell
-source ~/.bashrc
-```
-
-### Verify Installation
-
-```bash
-# Check all tools are available
-adb version
-emulator -version
-avdmanager list
-```
-
-## Resource-Aware Emulator Setup
-
-### ⚡ **Quick Start Recommendation**
-
-**For best results, always start with resource analysis:**
-
-```bash
-# 1. Check your system capabilities
-./scripts/avd-resource-checker.sh
-
-# 2. Use the generated optimal startup script
-/tmp/start-avd-TimeSafari_Emulator.sh
-
-# 3. Deploy your app
-npm run build:android:dev
-adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-```
-
-This prevents system lockups and ensures optimal performance.
-
-### AVD Resource Checker Script
-
-**New Feature**: TimeSafari includes an intelligent resource checker that automatically detects your system capabilities and recommends optimal AVD configurations.
-
-```bash
-# Check system resources and get recommendations
-./scripts/avd-resource-checker.sh
-
-# Check resources for specific AVD
-./scripts/avd-resource-checker.sh TimeSafari_Emulator
-
-# Test AVD startup performance
-./scripts/avd-resource-checker.sh TimeSafari_Emulator --test
-
-# Create optimized AVD with recommended settings
-./scripts/avd-resource-checker.sh TimeSafari_Emulator --create
-```
-
-**What the script analyzes:**
-- **System Memory**: Total and available RAM
-- **CPU Cores**: Available processing power
-- **GPU Capabilities**: NVIDIA, AMD, Intel, or software rendering
-- **Hardware Acceleration**: Optimal graphics settings
-
-**What it generates:**
-- **Optimal configuration**: Memory, cores, and GPU settings
-- **Startup command**: Ready-to-use emulator command
-- **Startup script**: Saved to `/tmp/start-avd-{name}.sh` for reuse
-
-## Emulator Management
-
-### Create Android Virtual Device (AVD)
-
-```bash
-# List available system images
-avdmanager list target
-
-# Create AVD for API 34
-avdmanager create avd \
-  --name "TimeSafari_Emulator" \
-  --package "system-images;android-34;google_apis;x86_64" \
-  --device "pixel_7"
-
-# List created AVDs
-avdmanager list avd
-```
-
-### Start Emulator
-
-```bash
-# Start emulator with hardware acceleration (recommended)
-emulator -avd TimeSafari_Emulator -gpu host -no-audio &
-
-# Start with reduced resources (if system has limited RAM)
-emulator -avd TimeSafari_Emulator \
-  -no-audio \
-  -memory 2048 \
-  -cores 2 \
-  -gpu swiftshader_indirect &
-
-# Start with minimal resources (safest for low-end systems)
-emulator -avd TimeSafari_Emulator \
-  -no-audio \
-  -memory 1536 \
-  -cores 1 \
-  -gpu swiftshader_indirect &
-
-# Check if emulator is running
-adb devices
-```
-
-### Resource Management
-
-**Important**: Android emulators can consume significant system resources. Choose the appropriate configuration based on your system:
-
-- **High-end systems** (16GB+ RAM, dedicated GPU): Use `-gpu host`
-- **Mid-range systems** (8-16GB RAM): Use `-memory 2048 -cores 2`
-- **Low-end systems** (4-8GB RAM): Use `-memory 1536 -cores 1 -gpu swiftshader_indirect`
-
-### Emulator Control
-
-```bash
-# Stop emulator
-adb emu kill
-
-# Restart emulator
-adb reboot
-
-# Check emulator status
-adb get-state
-```
-
-## Build and Deploy Workflow
-
-### Method 1: Using Existing Build Scripts
-
-The TimeSafari project already has comprehensive Android build scripts that can be adapted for emulator deployment:
-
-```bash
-# Development build with auto-run
-npm run build:android:dev:run
-
-# Test build with auto-run  
-npm run build:android:test:run
-
-# Production build with auto-run
-npm run build:android:prod:run
-```
-
-### Method 2: Custom Emulator Deployment Script
-
-Create a new script specifically for emulator deployment:
-
-```bash
-# Create emulator deployment script
-cat > scripts/deploy-android-emulator.sh << 'EOF'
-#!/bin/bash
-# deploy-android-emulator.sh
-# Author: Matthew Raymer
-# Date: 2025-01-27
-# Description: Deploy TimeSafari to Android emulator without Android Studio
-
-set -e
-
-# Source common utilities
-source "$(dirname "$0")/common.sh"
-
-# Default values
-BUILD_MODE="development"
-AVD_NAME="TimeSafari_Emulator"
-START_EMULATOR=true
-CLEAN_BUILD=true
-
-# Parse command line arguments
-while [[ $# -gt 0 ]]; do
-    case $1 in
-        --dev|--development)
-            BUILD_MODE="development"
-            shift
-            ;;
-        --test)
-            BUILD_MODE="test"
-            shift
-            ;;
-        --prod|--production)
-            BUILD_MODE="production"
-            shift
-            ;;
-        --avd)
-            AVD_NAME="$2"
-            shift 2
-            ;;
-        --no-start-emulator)
-            START_EMULATOR=false
-            shift
-            ;;
-        --no-clean)
-            CLEAN_BUILD=false
-            shift
-            ;;
-        -h|--help)
-            echo "Usage: $0 [options]"
-            echo "Options:"
-            echo "  --dev, --development    Build for development"
-            echo "  --test                  Build for testing"
-            echo "  --prod, --production    Build for production"
-            echo "  --avd NAME              Use specific AVD name"
-            echo "  --no-start-emulator     Don't start emulator"
-            echo "  --no-clean              Skip clean build"
-            echo "  -h, --help             Show this help"
-            exit 0
-            ;;
-        *)
-            log_error "Unknown option: $1"
-            exit 1
-            ;;
-    esac
-done
-
-# Function to check if emulator is running
-check_emulator_running() {
-    if adb devices | grep -q "emulator.*device"; then
-        return 0
-    else
-        return 1
-    fi
-}
-
-# Function to start emulator
-start_emulator() {
-    log_info "Starting Android emulator: $AVD_NAME"
-    
-    # Check if AVD exists
-    if ! avdmanager list avd | grep -q "$AVD_NAME"; then
-        log_error "AVD '$AVD_NAME' not found. Please create it first."
-        log_info "Create AVD with: avdmanager create avd --name $AVD_NAME --package system-images;android-34;google_apis;x86_64"
-        exit 1
-    fi
-    
-    # Start emulator in background
-    emulator -avd "$AVD_NAME" -no-audio -no-snapshot &
-    EMULATOR_PID=$!
-    
-    # Wait for emulator to boot
-    log_info "Waiting for emulator to boot..."
-    adb wait-for-device
-    
-    # Wait for boot to complete
-    log_info "Waiting for boot to complete..."
-    while [ "$(adb shell getprop sys.boot_completed)" != "1" ]; do
-        sleep 2
-    done
-    
-    log_success "Emulator is ready!"
-}
-
-# Function to build and deploy
-build_and_deploy() {
-    log_info "Building TimeSafari for $BUILD_MODE mode..."
-    
-    # Clean build if requested
-    if [ "$CLEAN_BUILD" = true ]; then
-        log_info "Cleaning previous build..."
-        npm run clean:android
-    fi
-    
-    # Build based on mode
-    case $BUILD_MODE in
-        "development")
-            npm run build:android:dev
-            ;;
-        "test")
-            npm run build:android:test
-            ;;
-        "production")
-            npm run build:android:prod
-            ;;
-    esac
-    
-    # Deploy to emulator
-    log_info "Deploying to emulator..."
-    adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-    
-    # Launch app
-    log_info "Launching TimeSafari..."
-    adb shell am start -n app.timesafari/.MainActivity
-    
-    log_success "TimeSafari deployed and launched successfully!"
-}
-
-# Main execution
-main() {
-    log_info "TimeSafari Android Emulator Deployment"
-    log_info "Build Mode: $BUILD_MODE"
-    log_info "AVD Name: $AVD_NAME"
-    
-    # Start emulator if requested and not running
-    if [ "$START_EMULATOR" = true ]; then
-        if ! check_emulator_running; then
-            start_emulator
-        else
-            log_info "Emulator already running"
-        fi
-    fi
-    
-    # Build and deploy
-    build_and_deploy
-    
-    log_success "Deployment completed successfully!"
-}
-
-# Run main function
-main "$@"
-EOF
-
-# Make script executable
-chmod +x scripts/deploy-android-emulator.sh
-```
-
-### Method 3: Direct Command Line Deployment
-
-For quick deployments without scripts:
-
-```bash
-# 1. Ensure emulator is running
-adb devices
-
-# 2. Build the app
-npm run build:android:dev
-
-# 3. Install APK
-adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-
-# 4. Launch app
-adb shell am start -n app.timesafari/.MainActivity
-
-# 5. View logs
-adb logcat | grep -E "(TimeSafari|Capacitor|MainActivity)"
-```
-
-## Advanced Deployment Options
-
-### Custom API Server Configuration
-
-For development with custom API endpoints:
-
-```bash
-# Build with custom API IP
-npm run build:android:dev:custom
-
-# Or modify capacitor.config.ts for specific IP
-# Then build normally
-npm run build:android:dev
-```
-
-### Debug vs Release Builds
-
-```bash
-# Debug build (default)
-npm run build:android:debug
-
-# Release build
-npm run build:android:release
-
-# Install specific build
-adb install -r android/app/build/outputs/apk/release/app-release.apk
-```
-
-### Asset Management
-
-```bash
-# Validate Android assets
-npm run assets:validate:android
-
-# Generate assets only
-npm run build:android:assets
-
-# Clean assets
-npm run assets:clean
-```
-
-## Troubleshooting
-
-### Common Issues
-
-1. **Emulator Not Starting / AVD Not Found**
-   ```bash
-   # Check available AVDs
-   avdmanager list avd
-   
-   # If AVD exists but emulator can't find it, check AVD location
-   echo $ANDROID_AVD_HOME
-   ls -la ~/.android/avd/
-   
-   # Fix AVD path issue (common on Arch Linux)
-   export ANDROID_AVD_HOME=/home/$USER/.config/.android/avd
-   
-   # Or create symlinks if AVDs are in different location
-   mkdir -p ~/.android/avd
-   ln -s /home/$USER/.config/.android/avd/* ~/.android/avd/
-   
-   # Create new AVD if needed
-   avdmanager create avd --name "TimeSafari_Emulator" --package "system-images;android-34;google_apis;x86_64"
-   
-   # Check emulator logs
-   emulator -avd TimeSafari_Emulator -verbose
-   ```
-
-2. **System Lockup / High Resource Usage**
-   ```bash
-   # Kill any stuck emulator processes
-   pkill -f emulator
-   
-   # Check system resources
-   free -h
-   nvidia-smi  # if using NVIDIA GPU
-   
-   # Start with minimal resources
-   emulator -avd TimeSafari_Emulator \
-     -no-audio \
-     -memory 1536 \
-     -cores 1 \
-     -gpu swiftshader_indirect &
-   
-   # Monitor resource usage
-   htop
-   
-   # If still having issues, try software rendering only
-   emulator -avd TimeSafari_Emulator \
-     -no-audio \
-     -no-snapshot \
-     -memory 1024 \
-     -cores 1 \
-     -gpu off &
-   ```
-
-3. **ADB Device Not Found**
-   ```bash
-   # Restart ADB server
-   adb kill-server
-   adb start-server
-   
-   # Check devices
-   adb devices
-   
-   # Check emulator status
-   adb get-state
-   ```
-
-3. **Build Failures**
-   ```bash
-   # Clean everything
-   npm run clean:android
-   
-   # Rebuild
-   npm run build:android:dev
-   
-   # Check Gradle logs
-   cd android && ./gradlew clean --stacktrace
-   ```
-
-4. **Installation Failures**
-   ```bash
-   # Uninstall existing app
-   adb uninstall app.timesafari
-   
-   # Reinstall
-   adb install android/app/build/outputs/apk/debug/app-debug.apk
-   
-   # Check package info
-   adb shell pm list packages | grep timesafari
-   ```
-
-### Performance Optimization
-
-1. **Emulator Performance**
-   ```bash
-   # Start with hardware acceleration
-   emulator -avd TimeSafari_Emulator -gpu host
-   
-   # Use snapshot for faster startup
-   emulator -avd TimeSafari_Emulator -snapshot default
-   
-   # Allocate more RAM
-   emulator -avd TimeSafari_Emulator -memory 4096
-   ```
-
-2. **Build Performance**
-   ```bash
-   # Use Gradle daemon
-   echo "org.gradle.daemon=true" >> android/gradle.properties
-   
-   # Increase heap size
-   echo "org.gradle.jvmargs=-Xmx4g" >> android/gradle.properties
-   
-   # Enable parallel builds
-   echo "org.gradle.parallel=true" >> android/gradle.properties
-   ```
-
-## Integration with Existing Build System
-
-### NPM Scripts Integration
-
-Add emulator-specific scripts to `package.json`:
-
-```json
-{
-  "scripts": {
-    "emulator:check": "./scripts/avd-resource-checker.sh",
-    "emulator:check:test": "./scripts/avd-resource-checker.sh TimeSafari_Emulator --test",
-    "emulator:check:create": "./scripts/avd-resource-checker.sh TimeSafari_Emulator --create",
-    "emulator:start": "emulator -avd TimeSafari_Emulator -no-audio &",
-    "emulator:start:optimized": "/tmp/start-avd-TimeSafari_Emulator.sh",
-    "emulator:stop": "adb emu kill",
-    "emulator:deploy": "./scripts/deploy-android-emulator.sh",
-    "emulator:deploy:dev": "./scripts/deploy-android-emulator.sh --dev",
-    "emulator:deploy:test": "./scripts/deploy-android-emulator.sh --test",
-    "emulator:deploy:prod": "./scripts/deploy-android-emulator.sh --prod",
-    "emulator:logs": "adb logcat | grep -E '(TimeSafari|Capacitor|MainActivity)'",
-    "emulator:shell": "adb shell"
-  }
-}
-```
-
-### CI/CD Integration
-
-For automated testing and deployment:
-
-```bash
-# GitHub Actions example
-- name: Start Android Emulator
-  run: |
-    emulator -avd TimeSafari_Emulator -no-audio -no-snapshot &
-    adb wait-for-device
-    adb shell getprop sys.boot_completed
-
-- name: Build and Deploy
-  run: |
-    npm run build:android:test
-    adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-    adb shell am start -n app.timesafari/.MainActivity
-
-- name: Run Tests
-  run: |
-    npm run test:android
-```
-
-## Best Practices
-
-### Development Workflow
-
-1. **Start emulator once per session**
-   ```bash
-   emulator -avd TimeSafari_Emulator -no-audio &
-   ```
-
-2. **Use incremental builds**
-   ```bash
-   # For rapid iteration
-   npm run build:android:sync
-   adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-   ```
-
-3. **Monitor logs continuously**
-   ```bash
-   adb logcat | grep -E "(TimeSafari|Capacitor|MainActivity)" --color=always
-   ```
-
-### Performance Tips
-
-1. **Use snapshots for faster startup**
-2. **Enable hardware acceleration**
-3. **Allocate sufficient RAM (4GB+)**
-4. **Use SSD storage for AVDs**
-5. **Close unnecessary applications**
-
-### Security Considerations
-
-1. **Use debug builds for development only**
-2. **Never commit debug keystores**
-3. **Use release builds for testing**
-4. **Validate API endpoints in production builds**
-
-## Conclusion
-
-This guide provides a complete solution for deploying TimeSafari to Android emulators without Android Studio. The approach leverages the existing build system while adding emulator-specific deployment capabilities.
-
-The key benefits:
-- ✅ **No Android Studio required**
-- ✅ **Command-line only workflow**
-- ✅ **Integration with existing build scripts**
-- ✅ **Automated deployment options**
-- ✅ **Comprehensive troubleshooting guide**
-
-For questions or issues, refer to the troubleshooting section or check the existing build documentation in `BUILDING.md`.

doc/android-physical-device-guide.md

@@ -1,516 +0,0 @@
-# Android Physical Device Deployment Guide
-
-**Author**: Matthew Raymer  
-**Date**: 2025-02-12  
-**Status**: 🎯 **ACTIVE** - Complete guide for deploying TimeSafari to physical Android devices
-
-## Overview
-
-This guide provides comprehensive instructions for building and deploying TimeSafari to physical Android devices for testing and development. Unlike emulator testing, physical device testing requires additional setup for USB connections and network configuration.
-
-## Prerequisites
-
-### Required Tools
-
-1. **Android SDK Platform Tools** (includes `adb`)
-   ```bash
-   # macOS (Homebrew)
-   brew install android-platform-tools
-   
-   # Or via Android SDK Manager
-   sdkmanager "platform-tools"
-   ```
-
-2. **Node.js 18+** and npm
-
-3. **Java Development Kit (JDK) 17+**
-   ```bash
-   # macOS (Homebrew)
-   brew install openjdk@17
-   
-   # Verify installation
-   java -version
-   ```
-
-### Environment Setup
-
-Add to your shell configuration (`~/.zshrc` or `~/.bashrc`):
-
-```bash
-# Android SDK location
-export ANDROID_HOME=$HOME/Library/Android/sdk  # macOS default
-# export ANDROID_HOME=$HOME/Android/Sdk        # Linux default
-
-export PATH=$PATH:$ANDROID_HOME/platform-tools
-export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
-export PATH=$PATH:$ANDROID_HOME/build-tools/34.0.0
-```
-
-Reload your shell:
-
-```bash
-source ~/.zshrc  # or source ~/.bashrc
-```
-
-Verify installation:
-
-```bash
-adb version
-```
-
-## Device Setup
-
-### Step 1: Enable Developer Options
-
-Developer Options is hidden by default on Android devices. To enable it:
-
-1. Open **Settings** on your Android device
-2. Scroll down and tap **About phone** (or **About device**)
-3. Find **Build number** and tap it **7 times** rapidly
-4. You'll see a message: "You are now a developer!"
-5. Go back to Settings - **Developer options** now appears
-
-### Step 2: Enable USB Debugging
-
-1. Go to **Settings** → **Developer options**
-2. Enable **USB debugging** (toggle it ON)
-3. Optionally enable these helpful options:
-   - **Stay awake** - Screen stays on while charging
-   - **Install via USB** - Allow app installations via USB
-
-### Step 3: Connect Your Device
-
-1. Connect your Android device to your computer via USB cable
-2. On your device, you'll see a prompt: "Allow USB debugging?"
-3. Check **"Always allow from this computer"** (recommended)
-4. Tap **Allow**
-
-### Step 4: Verify Connection
-
-```bash
-# List connected devices
-adb devices
-
-# Expected output:
-# List of devices attached
-# XXXXXXXXXX    device
-```
-
-If you see `unauthorized` instead of `device`, check your phone for the USB debugging authorization prompt.
-
-## Network Configuration for Development
-
-### Understanding the Network Challenge
-
-When running a local development server on your computer:
-- **Emulators** use `10.0.2.2` to reach the host machine
-- **Physical devices** need your computer's actual LAN IP address
-
-### Step 1: Find Your Computer's IP Address
-
-```bash
-# macOS
-ipconfig getifaddr en0    # Wi-Fi
-# or
-ipconfig getifaddr en1    # Ethernet
-
-# Linux
-hostname -I | awk '{print $1}'
-# or
-ip addr show | grep 'inet ' | grep -v '127.0.0.1' | awk '{print $2}' | cut -d'/' -f1
-```
-
-Example output: `192.168.1.100`
-
-### Step 2: Ensure Same Network
-
-Your Android device and computer **must be on the same Wi-Fi network** for the device to reach your local development servers.
-
-### Step 3: Configure API Endpoints
-
-Create or edit `.env.development` with your computer's IP:
-
-```bash
-# .env.development - for physical device testing
-VITE_DEFAULT_ENDORSER_API_SERVER=http://192.168.1.100:3000
-VITE_DEFAULT_PARTNER_API_SERVER=http://192.168.1.100:3000
-VITE_DEFAULT_IMAGE_API_SERVER=https://test-image-api.timesafari.app
-VITE_DEFAULT_NOTIFY_API_SERVER=https://test-notify-api.timesafari.app
-VITE_APP_SERVER=http://192.168.1.100:8080
-```
-
-**Important**: Replace `192.168.1.100` with your actual IP address.
-
-### Step 4: Start Your Local Server
-
-If testing against local API servers, ensure they're accessible from the network:
-
-```bash
-# Start your API server bound to all interfaces (not just localhost)
-# Example for Node.js:
-node server.js --host 0.0.0.0
-
-# Or configure your server to listen on 0.0.0.0 instead of 127.0.0.1
-```
-
-### Alternative: Use Test/Production Servers
-
-For simpler testing without local servers, use the test environment:
-
-```bash
-# Build with test API servers (no local server needed)
-npm run build:android:test
-```
-
-## Building and Deploying
-
-### Quick Start (Recommended)
-
-```bash
-# 1. Verify device is connected
-adb devices
-
-# 2. Build and deploy in one command
-npm run build:android:debug:run
-```
-
-### Step-by-Step Deployment
-
-#### Step 1: Build the App
-
-```bash
-# Development build (uses .env.development)
-npm run build:android:dev
-
-# Test build (uses test API servers)
-npm run build:android:test
-
-# Production build
-npm run build:android:prod
-```
-
-#### Step 2: Install the APK
-
-```bash
-# Install (replace existing if present)
-adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-```
-
-#### Step 3: Launch the App
-
-```bash
-# Start the app
-adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
-```
-
-### One-Line Deploy Commands
-
-```bash
-# Development build + install + launch
-npm run build:android:debug:run
-
-# Test build + install + launch
-npm run build:android:test:run
-
-# Deploy to connected device (build must exist)
-npm run build:android:deploy
-```
-
-## Debugging
-
-### View App Logs
-
-```bash
-# All logs from your app
-adb logcat | grep -E "(TimeSafari|Capacitor)"
-
-# With color highlighting
-adb logcat | grep -E "(TimeSafari|Capacitor)" --color=always
-
-# Save logs to file
-adb logcat > device-logs.txt
-```
-
-### Chrome DevTools (Remote Debugging)
-
-1. Open Chrome on your computer
-2. Navigate to `chrome://inspect`
-3. Your device should appear under "Remote Target"
-4. Click **inspect** to open DevTools for your app
-
-**Requirements**:
-- USB debugging must be enabled
-- Device must be connected via USB
-- App must be a debug build
-
-### Common Log Filters
-
-```bash
-# Network-related issues
-adb logcat | grep -i "network\|http\|socket"
-
-# JavaScript errors
-adb logcat | grep -i "console\|error\|exception"
-
-# Capacitor plugin issues
-adb logcat | grep -i "capacitor"
-
-# Detailed app logs
-adb logcat -s "TimeSafari:V"
-```
-
-## Troubleshooting
-
-### Device Not Detected
-
-**Symptom**: `adb devices` shows nothing or shows `unauthorized`
-
-**Solutions**:
-
-1. **Check USB cable**: Some cables are charge-only. Use a data-capable USB cable.
-
-2. **Revoke USB debugging authorizations** (on device):
-   - Settings → Developer options → Revoke USB debugging authorizations
-   - Reconnect and re-authorize
-
-3. **Restart ADB server**:
-   ```bash
-   adb kill-server
-   adb start-server
-   adb devices
-   ```
-
-4. **Try different USB port**: Some USB hubs don't work well with ADB.
-
-5. **Check device USB mode**: Pull down notification shade and ensure USB is set to "File Transfer" or "MTP" mode, not just charging.
-
-### App Can't Connect to Local Server
-
-**Symptom**: App loads but shows network errors or can't reach API
-
-**Solutions**:
-
-1. **Verify IP address**:
-   ```bash
-   # Make sure you have the right IP
-   ipconfig getifaddr en0  # macOS
-   ```
-
-2. **Check firewall**: Temporarily disable firewall or add exception for port 3000
-
-3. **Test connectivity from device**:
-   - Open Chrome on your Android device
-   - Navigate to `http://YOUR_IP:3000`
-   - Should see your API response
-
-4. **Verify server is listening on all interfaces**:
-   ```bash
-   # Should show 0.0.0.0:3000, not 127.0.0.1:3000
-   lsof -i :3000
-   ```
-
-5. **Same network check**: Ensure phone Wi-Fi and computer are on the same network
-
-### Installation Failed
-
-**Symptom**: `adb install` fails with error
-
-**Common errors and solutions**:
-
-1. **INSTALL_FAILED_UPDATE_INCOMPATIBLE**:
-   ```bash
-   # Uninstall existing app first
-   adb uninstall app.timesafari.app
-   adb install android/app/build/outputs/apk/debug/app-debug.apk
-   ```
-
-2. **INSTALL_FAILED_INSUFFICIENT_STORAGE**:
-   - Free up space on the device
-   - Or install to SD card if available
-
-3. **INSTALL_FAILED_USER_RESTRICTED**:
-   - Enable "Install via USB" in Developer options
-   - On some devices: Settings → Security → Unknown sources
-
-4. **Signature mismatch**:
-   ```bash
-   # Full clean reinstall
-   adb uninstall app.timesafari.app
-   npm run clean:android
-   npm run build:android:debug
-   adb install android/app/build/outputs/apk/debug/app-debug.apk
-   ```
-
-### App Crashes on Launch
-
-**Symptom**: App opens briefly then closes
-
-**Debug steps**:
-
-1. **Check crash logs**:
-   ```bash
-   adb logcat | grep -E "FATAL|AndroidRuntime|Exception"
-   ```
-
-2. **Clear app data**:
-   ```bash
-   adb shell pm clear app.timesafari.app
-   ```
-
-3. **Reinstall clean**:
-   ```bash
-   adb uninstall app.timesafari.app
-   npm run clean:android
-   npm run build:android:debug:run
-   ```
-
-### Build Failures
-
-**Symptom**: Build fails before APK is created
-
-**Solutions**:
-
-1. **Asset validation**:
-   ```bash
-   npm run assets:validate:android
-   ```
-
-2. **Clean and rebuild**:
-   ```bash
-   npm run clean:android
-   npm run build:android:debug
-   ```
-
-3. **Check Gradle**:
-   ```bash
-   cd android
-   ./gradlew clean --stacktrace
-   ./gradlew assembleDebug --stacktrace
-   ```
-
-## Wireless Debugging (Optional)
-
-Once initial USB connection is established, you can switch to wireless:
-
-### Enable Wireless Debugging
-
-```bash
-# 1. Connect via USB first
-adb devices
-
-# 2. Enable TCP/IP mode on port 5555
-adb tcpip 5555
-
-# 3. Find device IP (on device: Settings → About → IP address)
-# Or:
-adb shell ip addr show wlan0
-
-# 4. Connect wirelessly (disconnect USB cable)
-adb connect 192.168.1.XXX:5555
-
-# 5. Verify
-adb devices
-```
-
-### Reconnect After Reboot
-
-```bash
-# Device IP may have changed - check it first
-adb connect 192.168.1.XXX:5555
-```
-
-### Return to USB Mode
-
-```bash
-adb usb
-```
-
-## Best Practices
-
-### Development Workflow
-
-1. **Keep device connected during development** for quick iteration
-
-2. **Use test builds for most testing**:
-   ```bash
-   npm run build:android:test:run
-   ```
-   This avoids local server configuration hassles.
-
-3. **Use Chrome DevTools** for JavaScript debugging - much easier than logcat
-
-4. **Test on multiple devices** if possible - different Android versions behave differently
-
-### Performance Testing
-
-Physical devices give you real-world performance insights that emulators can't:
-
-- **Battery consumption**: Monitor with Settings → Battery
-- **Network conditions**: Test on slow/unstable Wi-Fi
-- **Memory pressure**: Test with many apps open
-- **Touch responsiveness**: Actual finger input vs mouse clicks
-
-### Before Release Testing
-
-Always test on physical devices before any release:
-
-1. Fresh install (not upgrade)
-2. Upgrade from previous version
-3. Test on lowest supported Android version
-4. Test on both phone and tablet if applicable
-
-## Quick Reference
-
-### Essential Commands
-
-```bash
-# Check connected devices
-adb devices
-
-# Build and run (debug)
-npm run build:android:debug:run
-
-# Build and run (test environment)
-npm run build:android:test:run
-
-# Install existing APK
-adb install -r android/app/build/outputs/apk/debug/app-debug.apk
-
-# Uninstall app
-adb uninstall app.timesafari.app
-
-# Launch app
-adb shell am start -n app.timesafari.app/app.timesafari.MainActivity
-
-# View logs
-adb logcat | grep TimeSafari
-
-# Take screenshot
-adb exec-out screencap -p > screenshot.png
-
-# Record screen
-adb shell screenrecord /sdcard/demo.mp4
-# (Ctrl+C to stop, then pull file)
-adb pull /sdcard/demo.mp4
-```
-
-### Build Modes Quick Reference
-
-| Command | Environment | API Servers |
-|---------|-------------|-------------|
-| `npm run build:android:dev` | Development | Local (your IP:3000) |
-| `npm run build:android:test` | Test | test-api.endorser.ch |
-| `npm run build:android:prod` | Production | api.endorser.ch |
-
-## Conclusion
-
-Physical device testing is essential for:
-- ✅ Real-world performance validation
-- ✅ Touch and gesture testing
-- ✅ Camera and hardware feature testing
-- ✅ Network condition testing
-- ✅ Battery and resource usage analysis
-
-For emulator-based testing (useful for quick iteration), see [Android Emulator Deployment Guide](android-emulator-deployment-guide.md).
-
-For questions or additional troubleshooting, refer to the main [BUILDING.md](../BUILDING.md) documentation.

doc/architecture-decisions.md

@@ -122,4 +122,4 @@ export default class HomeView extends Vue {
 
 ---
 
-*This decision was made based on the current codebase architecture and team expertise. The mixin approach provides the best balance of performance, developer experience, and architectural consistency for the TimeSafari application.*
+_This decision was made based on the current codebase architecture and team expertise. The mixin approach provides the best balance of performance, developer experience, and architectural consistency for the TimeSafari application._

doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md

@@ -1,80 +0,0 @@
-# Consuming app handoff: iOS native fetcher + chained dual (mirror)
-
-**Canonical source:** `daily-notification-plugin` repo, `doc/CONSUMING_APP_HANDOFF_IOS_NATIVE_FETCHER_AND_CHAINED_DUAL.md` (same content as below for offline use).
-
----
-
-## Implemented in this app
-
-- **`ios/App/App/TimeSafariNativeFetcher.swift`** — Swift `NativeNotificationContentFetcher` mirroring `TimeSafariNativeFetcher.java` (`POST …/plansLastUpdatedBetween`, starred IDs from `daily_notification_timesafari.starredPlanIds`, JWT pool selection, pagination key `daily_notification_timesafari.last_acked_jwt_id`, aggregated copy).
-- **`AppDelegate.swift`** — `DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)` at launch **before** any JS `configureNativeFetcher`; foreground handler reads `scheduled_time` as `Int64`, `NSNumber`, or `Int` for `DailyNotificationDelivered`.
-
-## Dependency
-
-- **`@timesafari/daily-notification-plugin`** must be **≥ 3.0.0** (register native fetcher, chained dual, iOS `updateStarredPlans`). Declare it in `package.json` from the official remote (`git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git`, branch or tag as needed), then `npm install` so `package-lock.json` resolves the published tree.
-
-## Bump / sync (after plugin version is resolved)
-
-1. `npm install`
-2. `npx cap sync ios && npx cap sync android`
-3. `cd ios/App && pod install`
-4. Clean build in Xcode / Android Studio
-
-## QA focus
-
-- iOS: Fetcher registered before `configureNativeFetcher`; `updateStarredPlans` not `UNIMPLEMENTED`.
-- Both: New Activity fires **after** prefetch for that cycle where the plugin implements chaining.
-- Android: Existing `MainActivity.setNativeFetcher` unchanged; regression-test `cancelDualSchedule` vs Daily Reminder.
-
----
-
-## Original handoff text (from plugin)
-
-This document is for the **host app** repository (e.g. crowd-funder-for-time-pwa) after bumping `@timesafari/daily-notification-plugin` to a version that includes:
-
-- **iOS** `NativeNotificationContentFetcher`–style registration (`DailyNotificationPlugin.registerNativeFetcher`)
-- **iOS** `updateStarredPlans` / `getStarredPlans` (parity with Android `daily_notification_timesafari` / `starredPlanIds` semantics)
-- **iOS** chained dual flow: user notification is **armed only after** prefetch completes (delay if fetch is late; max slip 15 minutes before fallback copy)
-- **Android** chained dual flow: exact **notify** alarm is scheduled **after** dual prefetch completes (no longer scheduled at initial `scheduleDualNotification` before fetch)
-
-Material from `doc/new-activity-notifications-ios-android-parity.md` still applies; the plugin doc adds **app-side** steps not spelled out there.
-
-### 1. iOS — register native fetcher before `configureNativeFetcher`
-
-The plugin **rejects** `configureNativeFetcher` if no fetcher is registered (aligned with Android).
-
-**In `AppDelegate` (or earliest app startup before Capacitor calls into the plugin):**
-
-```swift
-import TimesafariDailyNotificationPlugin
-
-DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)
-```
-
-Implement **`TimeSafariNativeFetcher`** as a Swift type that:
-
-- Conforms to `NativeNotificationContentFetcher`
-- Implements `fetchContent(context: FetchContext) async throws -> [NotificationContent]` with the same **Endorser** behavior as `TimeSafariNativeFetcher.java`
-- Implements `configure(apiBaseUrl:activeDid:jwtToken:jwtTokenPool:)` if the fetcher needs credentials pushed from TypeScript
-
-**Starred plan IDs for the fetcher:** Read JSON array string from UserDefaults key **`daily_notification_timesafari.starredPlanIds`** (written by `updateStarredPlans` from JS).
-
-### 2. iOS — `UNUserNotificationCenterDelegate` / rollover
-
-Chained dual notifications set:
-
-- `notification_id` = `org.timesafari.dailynotification.dual`
-- `scheduled_time` = `NSNumber` (fire time in ms)
-
-Ensure **`DailyNotificationDelivered`** forwards **`notification_id`** and **`scheduled_time`** from **notification content `userInfo`**.
-
-### 3. Android — no API change for `setNativeFetcher`
-
-Host apps that already call `DailyNotificationPlugin.setNativeFetcher(TimeSafariNativeFetcher(...))` keep that flow.
-
-**Behavior change:** the dual **notify** alarm is scheduled when **dual prefetch work finishes**, not at the initial `scheduleDualNotification` only.
-
-### 4. Assumptions
-
-- Swift host implements `TimeSafariNativeFetcher`; the plugin does **not** embed `plansLastUpdatedBetween` on iOS when a host fetcher is registered (mirrors Android).
-- Module import: `TimesafariDailyNotificationPlugin` (Pod `TimesafariDailyNotificationPlugin`).

doc/daily-notification-alignment-outline.md

@@ -1,105 +0,0 @@
-# Daily Notification Plugin: Alignment Outline
-
-**Purpose:** Checklist of changes/additions needed in this app to align with the test app (`daily-notification-plugin/test-apps/daily-notification-test`) so that:
-
-1. **Rollover recovery** (and rollover itself) works.
-2. **Notifications show when the app is in the foreground** (not only background/closed).
-3. **Plugin loads at app launch** so recovery runs after reboot without the user opening notification UI.
-
-**Reference:** In the **daily-notification-plugin** repository, the test app lives at `test-apps/daily-notification-test` (same repo as `https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin`).
-
----
-
-## 1. iOS AppDelegate
-
-**File:** `ios/App/App/AppDelegate.swift`
-
-### 1.1 Add imports
-
-- [ ] `import UserNotifications`
-- [ ] Import the Daily Notification plugin framework (Swift module name: **TimesafariDailyNotificationPlugin** per this app’s Podfile; test app uses **DailyNotificationPlugin**)
-
-### 1.2 Conform to `UNUserNotificationCenterDelegate`
-
-- [ ] Add `, UNUserNotificationCenterDelegate` to the class declaration:  
-  `class AppDelegate: UIResponder, UIApplicationDelegate, UNUserNotificationCenterDelegate`
-
-### 1.3 Force-load plugin at launch
-
-- [ ] In `application(_:didFinishLaunchingWithOptions:)`, **before** other setup, add logic to force-load the plugin class (e.g. `_ = DailyNotificationPlugin.self` or the class exposed by the TimesafariDailyNotificationPlugin pod) so that the plugin’s `load()` (and thus `performRecovery()`) runs at app launch, not only when JS first calls the plugin.
-
-### 1.4 Set notification center delegate
-
-- [ ] In `didFinishLaunchingWithOptions`, set:  
-  `UNUserNotificationCenter.current().delegate = self`
-- [ ] In `applicationDidBecomeActive`, **re-set** the same delegate (in case Capacitor or another component clears it).
-
-### 1.5 Implement `userNotificationCenter(_:willPresent:withCompletionHandler:)`
-
-- [ ] When a notification is delivered (including in foreground), read `notification_id` and `scheduled_time` from `notification.request.content.userInfo`.
-- [ ] Post rollover event:  
-  `NotificationCenter.default.post(name: NSNotification.Name("DailyNotificationDelivered"), object: nil, userInfo: ["notification_id": id, "scheduled_time": scheduledTime])`
-- [ ] Call completion handler with presentation options so the notification is shown in foreground, e.g.  
-  `completionHandler([.banner, .sound, .badge])` (use `.alert` on iOS 13 if needed).
-
-### 1.6 Implement `userNotificationCenter(_:didReceive:withCompletionHandler:)`
-
-- [ ] Handle notification tap/interaction; call `completionHandler()` when done.
-
----
-
-## 2. Android Manifest
-
-**File:** `android/app/src/main/AndroidManifest.xml`
-
-### 2.1 Fix receiver placement
-
-- [ ] Move the two `<receiver>` elements (**DailyNotificationReceiver** and **BootReceiver**) **inside** the `<application>` block (e.g. after `<activity>...</activity>` and before `<provider>...</provider>`).
-- [ ] Remove the stray second `</application>` so there is a single `<application>...</application>` containing activity, receivers, and provider.
-
-### 2.2 (Optional) Add NotifyReceiver
-
-- [ ] If the plugin’s Android integration expects **NotifyReceiver** for alarm-based delivery, add a `<receiver>` for `org.timesafari.dailynotification.NotifyReceiver` inside `<application>` (see test app manifest for exact declaration).
-
-### 2.3 (Optional) BootReceiver options
-
-- [ ] Consider aligning with test app: add `android:directBootAware="true"`, `android:exported="true"`, and intent-filter actions `LOCKED_BOOT_COMPLETED`, `MY_PACKAGE_REPLACED`, `PACKAGE_REPLACED` if you need the same boot/update behavior.
-
----
-
-## 3. Capacitor / JS startup (optional but recommended)
-
-**File:** `src/main.capacitor.ts` (or the main entry used for native builds)
-
-### 3.1 Load plugin at startup
-
-- [ ] Add a top-level import or an early call that touches the Daily Notification plugin so the JS side loads it at app startup (e.g. `import "@timesafari/daily-notification-plugin"` or a small init that calls `getRebootRecoveryStatus()` or `configure()`).  
-  This ensures the plugin is loaded as soon as the app runs; together with the iOS force-load in AppDelegate, recovery runs at launch.
-
----
-
-## 4. Plugin configuration (optional)
-
-- [ ] If you use the native fetcher or need plugin config (db path, storage, etc.), call `DailyNotification.configure()` and/or `configureNativeFetcher()` when appropriate (e.g. after login or when notification UI is first used), similar to the test app’s `configureNativeFetcher()` in HomeView.
-
----
-
-## 5. Summary table
-
-| Area                    | Change / addition                                                                 |
-|-------------------------|------------------------------------------------------------------------------------|
-| **iOS AppDelegate**     | Conform to `UNUserNotificationCenterDelegate`; set delegate; force-load plugin; implement `willPresent` (post `DailyNotificationDelivered` + show in foreground) and `didReceive`. |
-| **Android manifest**    | Move DailyNotificationReceiver and BootReceiver inside `<application>`; remove duplicate `</application>`; optionally add NotifyReceiver and BootReceiver options. |
-| **main.capacitor.ts**  | Optionally import or call plugin at startup so it (and recovery) load at launch.  |
-| **Plugin config**      | Optionally call `configure()` / `configureNativeFetcher()` where appropriate.     |
-
----
-
-## 6. Verification
-
-After making the changes:
-
-- [ ] **iOS:** Build and run; trigger a daily notification and confirm it appears when the app is in the foreground.
-- [ ] **iOS:** Confirm rollover (next day’s schedule) still occurs after a notification fires (check logs for `DNP-ROLLOVER` / `DailyNotificationDelivered`).
-- [ ] **iOS:** Restart the app (or reboot) and confirm recovery runs without opening the notification settings screen (e.g. logs show plugin load and recovery).
-- [ ] **Android:** Build and run; confirm receivers are registered (no manifest errors) and that notifications and boot recovery behave as expected.

doc/daily-notification-plugin-android-receiver-issue.md

@@ -1,251 +0,0 @@
-# Daily Notification Plugin - Android Receiver Not Triggered by AlarmManager
-
-**Date**: 2026-02-02  
-**Status**: ✅ Resolved (2026-02-06)  
-**Plugin**: @timesafari/daily-notification-plugin  
-**Platform**: Android  
-**Issue**: AlarmManager fires alarms but DailyNotificationReceiver is not receiving broadcasts
-
----
-
-## Resolution (2026-02-06)
-
-The bug was fixed in the plugin repository. The plugin now:
-
-- Creates the PendingIntent with the receiver component explicitly set (`setComponent(ComponentName(context, DailyNotificationReceiver::class.java))`), so AlarmManager delivers the broadcast to the receiver.
-- Adds the schedule ID to the Intent extras (`intent.putExtra("id", scheduleId)`), resolving the `missing_id` error.
-
-**In this app after pulling the fix:**
-
-1. Run `npm install` to get the latest plugin from `#master`.
-2. Run `npx cap sync` so the Android (and iOS) native projects get the updated plugin code.
-3. Run `node scripts/restore-local-plugins.js` if you use local plugins (e.g. SafeArea, SharedImage).
-4. Rebuild and run on Android, then verify using the [Testing Steps for Plugin Fix](#testing-steps-for-plugin-fix) below.
-</think>
-
----
-
-## Problem Summary
-
-Alarms are being scheduled successfully and fire at the correct time, but the `DailyNotificationReceiver` is not being triggered when AlarmManager delivers the broadcast. Manual broadcasts to the receiver work correctly, indicating the receiver itself is functional.
-
----
-
-## What Works ✅
-
-1. **Receiver Registration**: The receiver is properly registered in AndroidManifest.xml with `exported="true"`
-2. **Manual Broadcasts**: Manually triggering the receiver via `adb shell am broadcast` successfully triggers it
-3. **Alarm Scheduling**: Alarms are successfully scheduled via `setAlarmClock()` and appear in `dumpsys alarm`
-4. **Alarm Firing**: Alarms fire at the scheduled time (confirmed by alarm disappearing from dumpsys)
-
----
-
-## What Doesn't Work ❌
-
-1. **Automatic Receiver Triggering**: When AlarmManager fires the alarm, the broadcast PendingIntent does not reach the receiver
-2. **No Logs on Alarm Fire**: No `DN|RECEIVE_START` logs appear when alarms fire automatically
-3. **Missing ID in Intent**: When manually tested, receiver shows `DN|RECEIVE_ERR missing_id` (separate issue but related)
-
----
-
-## Technical Details
-
-### Receiver Configuration
-
-**File**: `android/app/src/main/AndroidManifest.xml`
-
-```xml
-<receiver
-    android:name="org.timesafari.dailynotification.DailyNotificationReceiver"
-    android:enabled="true"
-    android:exported="true">
-    <intent-filter>
-        <action android:name="org.timesafari.daily.NOTIFICATION" />
-    </intent-filter>
-</receiver>
-```
-
-- ✅ `exported="true"` is set (required for AlarmManager broadcasts)
-- ✅ Intent action matches: `org.timesafari.daily.NOTIFICATION`
-- ✅ Receiver is inside `<application>` tag
-
-### Alarm Scheduling Evidence
-
-From logs when scheduling (23:51:32):
-```
-I DNP-SCHEDULE: Scheduling OS alarm: variant=ALARM_CLOCK, action=org.timesafari.daily.NOTIFICATION, triggerTime=1770105300000, requestCode=44490, scheduleId=timesafari_daily_reminder
-I DNP-NOTIFY: Alarm clock scheduled (setAlarmClock): triggerAt=1770105300000, requestCode=44490
-```
-
-From `dumpsys alarm` output:
-```
-RTC_WAKEUP #36: Alarm{7a8fb5e type 0 origWhen 1770148800000 whenElapsed 122488536 app.timesafari.app}
-  tag=*walarm*:org.timesafari.daily.NOTIFICATION
-  type=RTC_WAKEUP origWhen=2026-02-03 12:00:00.000 window=0 exactAllowReason=policy_permission
-  operation=PendingIntent{6fce955: PendingIntentRecord{5856f6a app.timesafari.app broadcastIntent}}
-```
-
-### Alarm Firing Evidence
-
-- Alarm scheduled for 23:55:00 (timestamp: 1770105300000)
-- At 23:55:00, alarm is no longer in `dumpsys alarm` (confirmed it fired)
-- **No `DN|RECEIVE_START` log at 23:55:00** (receiver was not triggered)
-
-### Manual Broadcast Test (Works)
-
-```bash
-adb shell am broadcast -a org.timesafari.daily.NOTIFICATION -n app.timesafari.app/org.timesafari.dailynotification.DailyNotificationReceiver
-```
-
-**Result**: ✅ Receiver triggered successfully
-```
-02-02 23:46:07.505  DailyNotificationReceiver  D  DN|RECEIVE_START action=org.timesafari.daily.NOTIFICATION
-02-02 23:46:07.506  DailyNotificationReceiver  W  DN|RECEIVE_ERR missing_id
-```
-
----
-
-## Root Cause Analysis
-
-The issue appears to be in how the PendingIntent is created when scheduling alarms. Possible causes:
-
-### Hypothesis 1: PendingIntent Not Targeting Receiver Correctly
-
-The PendingIntent may be created without explicitly specifying the component, causing Android to not match it to the receiver when the alarm fires.
-
-**Expected Fix**: When creating the PendingIntent for AlarmManager, explicitly set the component:
-
-```kotlin
-val intent = Intent("org.timesafari.daily.NOTIFICATION").apply {
-    setComponent(ComponentName(context, DailyNotificationReceiver::class.java))
-    putExtra("id", scheduleId) // Also fix missing_id issue
-}
-val pendingIntent = PendingIntent.getBroadcast(
-    context,
-    requestCode,
-    intent,
-    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
-)
-```
-
-### Hypothesis 2: PendingIntent Flags Issue
-
-The PendingIntent may be created with incorrect flags that prevent delivery when the app is in certain states.
-
-**Check**: Ensure flags include:
-- `FLAG_UPDATE_CURRENT` or `FLAG_CANCEL_CURRENT`
-- `FLAG_IMMUTABLE` (required on Android 12+)
-
-### Hypothesis 3: Package/Component Mismatch
-
-The PendingIntent may be created with a different package name or component than what's registered in the manifest.
-
-**Check**: Verify the package name in the Intent matches `app.timesafari.app` and the component matches the receiver class.
-
----
-
-## Additional Issue: Missing ID in Intent
-
-When the receiver IS triggered (manually), it shows:
-```
-DN|RECEIVE_ERR missing_id
-```
-
-This indicates the Intent extras don't include the `scheduleId`. The plugin should add the ID to the Intent when creating the PendingIntent:
-
-```kotlin
-intent.putExtra("id", scheduleId)
-// or
-intent.putExtra("scheduleId", scheduleId) // if receiver expects different key
-```
-
----
-
-## Testing Steps for Plugin Fix
-
-1. **Verify PendingIntent Creation**:
-   - Check the code that creates PendingIntent for AlarmManager
-   - Ensure component is explicitly set
-   - Ensure ID is added to Intent extras
-
-2. **Test Alarm Delivery**:
-   - Schedule an alarm for 1-2 minutes in the future
-   - Monitor logs: `adb logcat | grep -E "DN|RECEIVE_START|DailyNotification"`
-   - Verify `DN|RECEIVE_START` appears when alarm fires
-   - Verify no `missing_id` error
-
-3. **Test Different App States**:
-   - App in foreground
-   - App in background
-   - App force-closed
-   - Device in doze mode (if possible on emulator)
-
-4. **Compare with Manual Broadcast**:
-   - Manual broadcast works → receiver is fine
-   - Alarm broadcast doesn't work → PendingIntent creation is the issue
-
----
-
-## Files to Check in Plugin
-
-1. **Alarm Scheduling Code**: Where `setAlarmClock()` or `setExact()` is called
-2. **PendingIntent Creation**: Where `PendingIntent.getBroadcast()` is called
-3. **Intent Creation**: Where the Intent for the alarm is created
-4. **Receiver Code**: Verify what Intent extras it expects (for missing_id fix)
-
----
-
-## Related Configuration
-
-### AndroidManifest.xml (App Side)
-- ✅ Receiver exported="true"
-- ✅ Correct intent action
-- ✅ Receiver inside application tag
-
-### Permissions (App Side)
-- ✅ POST_NOTIFICATIONS
-- ✅ SCHEDULE_EXACT_ALARM
-- ✅ RECEIVE_BOOT_COMPLETED
-- ✅ WAKE_LOCK
-- ❌ USE_EXACT_ALARM -- must not use; see note below
-
-> **Note on `USE_EXACT_ALARM`:** The `USE_EXACT_ALARM` permission is restricted
-> by Google on Android. Apps that declare it must be primarily dedicated to alarm
-> or calendar functionality. Google will reject apps from the Play Store that use
-> this permission for other purposes. This plugin uses `SCHEDULE_EXACT_ALARM`
-> instead, which is sufficient for scheduling daily notifications.
-
----
-
-## Expected Behavior After Fix
-
-When an alarm fires:
-1. AlarmManager delivers the broadcast
-2. `DailyNotificationReceiver.onReceive()` is called
-3. Log shows: `DN|RECEIVE_START action=org.timesafari.daily.NOTIFICATION`
-4. Receiver finds the ID in Intent extras (no `missing_id` error)
-5. Notification is displayed
-
----
-
-## Notes
-
-- The `exported="true"` change in the app's manifest was necessary and correct
-- The issue is in the plugin's PendingIntent creation, not the app configuration
-- Manual broadcasts work, proving the receiver registration is correct
-- Alarms fire, proving AlarmManager scheduling is correct
-- The gap is in the PendingIntent → Receiver delivery
-
----
-
-## Quick Reference: Working Manual Test
-
-```bash
-# This works - receiver is triggered
-adb shell am broadcast \
-  -a org.timesafari.daily.NOTIFICATION \
-  -n app.timesafari.app/org.timesafari.dailynotification.DailyNotificationReceiver \
-  --es "id" "timesafari_daily_reminder"
-```
-
-The plugin's PendingIntent should create an equivalent broadcast that AlarmManager can deliver.

doc/daily-notification-plugin-architecture.md

@@ -1,312 +0,0 @@
-# Daily Notification Plugin - Architecture Overview
-
-## System Architecture
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                        Vue Components                            │
-│  (PushNotificationPermission.vue, AccountViewView.vue, etc.)    │
-└───────────────────────────┬─────────────────────────────────────┘
-                            │
-                            ▼
-┌─────────────────────────────────────────────────────────────────┐
-│              NotificationService (Factory)                       │
-│           - Platform detection via Capacitor API                 │
-│           - Singleton pattern                                    │
-│           - Returns appropriate implementation                   │
-└───────────────────────────┬─────────────────────────────────────┘
-                            │
-                ┌───────────┴────────────┐
-                ▼                        ▼
-┌───────────────────────────┐  ┌────────────────────────────┐
-│ NativeNotificationService │  │ WebPushNotificationService │
-│                           │  │                            │
-│ iOS/Android               │  │ Web/PWA                    │
-│ - UNUserNotificationCenter│  │ - Web Push API             │
-│ - NotificationManager     │  │ - Service Workers          │
-│ - AlarmManager            │  │ - VAPID keys               │
-│ - Background tasks        │  │ - Push server              │
-└─────────────┬─────────────┘  └────────────┬───────────────┘
-              │                              │
-              ▼                              ▼
-┌─────────────────────────┐  ┌──────────────────────────────┐
-│  DailyNotificationPlugin│  │  Existing Web Push Logic     │
-│  (Capacitor Plugin)     │  │  (PushNotificationPermission)│
-│                         │  │                              │
-│  - Native iOS code      │  │  - Service worker            │
-│  - Native Android code  │  │  - VAPID subscription        │
-│  - SQLite storage       │  │  - Push server integration   │
-└─────────────────────────┘  └──────────────────────────────┘
-```
-
-## Platform Decision Flow
-
-```
-User Action: Schedule Notification
-         │
-         ▼
-   NotificationService.getInstance()
-         │
-         ├──> Check: Capacitor.isNativePlatform()
-         │
-    ┌────┴─────┐
-    │          │
-   YES        NO
-    │          │
-    ▼          ▼
-Native      Web/PWA
-Service     Service
-    │          │
-    ▼          ▼
-Plugin      Web Push
-```
-
-## Data Flow Example: Scheduling a Notification
-
-### Native Platform (iOS/Android)
-```
-1. User clicks "Enable Notifications"
-   │
-2. PushNotificationPermission.vue
-   │
-   └─> NotificationService.getInstance()
-       │
-       └─> Returns NativeNotificationService (detected iOS/Android)
-           │
-           └─> nativeService.requestPermissions()
-               │
-               └─> DailyNotification.requestPermissions() [Capacitor Plugin]
-                   │
-                   └─> Native code requests OS permissions
-                       │
-                       └─> Returns: { granted: true/false }
-
-3. User sets time & message
-   │
-4. nativeService.scheduleDailyNotification({ time: '09:00', ... })
-   │
-   └─> DailyNotification.scheduleDailyReminder({ ... })
-       │
-       └─> Native code:
-           - Stores in SQLite
-           - Schedules AlarmManager (Android) or UNNotificationRequest (iOS)
-           - Returns: success/failure
-
-5. At 9:00 AM:
-   - Android: AlarmManager triggers → DailyNotificationReceiver
-   - iOS: UNUserNotificationCenter triggers notification
-   - Notification appears even if app is closed
-```
-
-### Web Platform
-```
-1. User clicks "Enable Notifications"
-   │
-2. PushNotificationPermission.vue
-   │
-   └─> NotificationService.getInstance()
-       │
-       └─> Returns WebPushNotificationService (detected web)
-           │
-           └─> webService.requestPermissions()
-               │
-               └─> Notification.requestPermission() [Browser API]
-                   │
-                   └─> Returns: 'granted'/'denied'/'default'
-
-3. User sets time & message
-   │
-4. webService.scheduleDailyNotification({ ... })
-   │
-   └─> [TODO] Subscribe to push service with VAPID
-       │
-       └─> Send subscription to server with schedule time
-           │
-           └─> Server sends push at scheduled time
-               │
-               └─> Service worker receives → shows notification
-```
-
-## File Organization
-
-```
-src/
-├── plugins/
-│   └── DailyNotificationPlugin.ts          [Plugin registration]
-│
-├── services/
-│   └── notifications/
-│       ├── index.ts                        [Barrel export]
-│       ├── NotificationService.ts          [Factory + Interface]
-│       ├── NativeNotificationService.ts    [iOS/Android impl]
-│       └── WebPushNotificationService.ts   [Web impl stub]
-│
-├── components/
-│   └── PushNotificationPermission.vue      [UI - to be updated]
-│
-└── views/
-    └── AccountViewView.vue                 [Settings UI]
-```
-
-## Key Design Decisions
-
-### 1. **Unified Interface**
-- Single `NotificationServiceInterface` for all platforms
-- Consistent API regardless of underlying implementation
-- Type-safe across TypeScript codebase
-
-### 2. **Runtime Platform Detection**
-- No build-time configuration needed
-- Same code bundle for all platforms
-- Factory pattern selects implementation automatically
-
-### 3. **Coexistence Strategy**
-- Web Push and Native run on different platforms
-- No conflicts - mutually exclusive at runtime
-- Allows gradual migration and testing
-
-### 4. **Singleton Pattern**
-- One service instance per app lifecycle
-- Efficient resource usage
-- Consistent state management
-
-## Permission Flow
-
-### Android
-```
-App Launch
-  ↓
-Check if POST_NOTIFICATIONS granted (API 33+)
-  │
-  ├─> YES: Ready to schedule
-  │
-  └─> NO: Request runtime permission
-          ↓
-      Show system dialog
-          ↓
-      User grants/denies
-          ↓
-      Schedule notifications (if granted)
-```
-
-### iOS
-```
-App Launch
-  ↓
-Check notification authorization status
-  │
-  ├─> authorized: Ready to schedule
-  │
-  ├─> notDetermined: Request permission
-  │       ↓
-  │   Show system dialog
-  │       ↓
-  │   User grants/denies
-  │
-  └─> denied: Guide user to Settings
-```
-
-### Web
-```
-App Load
-  ↓
-Check Notification.permission
-  │
-  ├─> "granted": Ready to subscribe
-  │
-  ├─> "default": Request permission
-  │       ↓
-  │   Show browser prompt
-  │       ↓
-  │   User grants/denies
-  │
-  └─> "denied": Cannot show notifications
-```
-
-## Error Handling Strategy
-
-```typescript
-// All methods return promises with success/failure
-try {
-  const granted = await service.requestPermissions();
-  if (granted) {
-    const success = await service.scheduleDailyNotification({...});
-    if (success) {
-      // Show success message
-    } else {
-      // Show scheduling error
-    }
-  } else {
-    // Show permission denied message
-  }
-} catch (error) {
-  // Log error and show generic error message
-  logger.error('Notification error:', error);
-}
-```
-
-## Background Execution
-
-### Native (iOS/Android)
-- ✅ Full background support
-- ✅ Survives app termination
-- ✅ Survives device reboot (with BootReceiver)
-- ✅ Exact alarm scheduling
-- ✅ Works offline
-
-### Web/PWA
-- ⚠️ Limited background support
-- ⚠️ Requires active service worker
-- ⚠️ Browser/OS dependent
-- ❌ Needs network for delivery
-- ⚠️ iOS: Only on Home Screen PWAs (16.4+)
-
-## Storage
-
-### Native
-```
-DailyNotificationPlugin
-    ↓
-SQLite Database (Room/Core Data)
-    ↓
-Stores:
-- Schedule configurations
-- Content cache
-- Delivery history
-- Callback registrations
-```
-
-### Web
-```
-Web Push
-    ↓
-IndexedDB (via Dexie)
-    ↓
-Stores:
-- Settings (notifyingNewActivityTime, etc.)
-- Push subscription info
-- VAPID keys
-```
-
-## Testing Strategy
-
-### Unit Testing
-- Mock `Capacitor.isNativePlatform()` to test both paths
-- Test factory returns correct implementation
-- Test each service implementation independently
-
-### Integration Testing
-- Test on actual devices (iOS/Android)
-- Test in browsers (Chrome, Safari, Firefox)
-- Verify notification delivery
-- Test permission flows
-
-### E2E Testing
-- Schedule notification → Wait → Verify delivery
-- Test app restart scenarios
-- Test device reboot scenarios
-- Test permission denial recovery
-
----
-
-**Key Takeaway**: The architecture provides a clean separation between platforms while maintaining a unified API for Vue components. Platform detection happens automatically at runtime, and the appropriate notification system is used transparently.

doc/daily-notification-plugin-checklist.md

@@ -1,348 +0,0 @@
-# Daily Notification Plugin - Integration Checklist
-
-**Integration Date**: 2026-01-21  
-**Plugin Version**: 1.0.11  
-**Status**: Phase 1 Complete ✅
-
----
-
-## Phase 1: Infrastructure Setup ✅ COMPLETE
-
-### Code Files
-- [x] Created `src/plugins/DailyNotificationPlugin.ts`
-- [x] Created `src/services/notifications/NotificationService.ts`
-- [x] Created `src/services/notifications/NativeNotificationService.ts`
-- [x] Created `src/services/notifications/WebPushNotificationService.ts`
-- [x] Created `src/services/notifications/index.ts`
-
-### Android Configuration
-
-> **Note on `USE_EXACT_ALARM`:** The `USE_EXACT_ALARM` permission is restricted
-> by Google on Android. Apps that declare it must be primarily dedicated to alarm
-> or calendar functionality. Google will reject apps from the Play Store that use
-> this permission for other purposes. This plugin uses `SCHEDULE_EXACT_ALARM`
-> instead, which is sufficient for scheduling daily notifications.
-
-- [x] Added permissions to `AndroidManifest.xml`:
-  - [x] `POST_NOTIFICATIONS`
-  - [x] `SCHEDULE_EXACT_ALARM`
-  - [x] `RECEIVE_BOOT_COMPLETED`
-  - [x] `WAKE_LOCK`
-  - [ ] `USE_EXACT_ALARM` -- must avoid; see note above
-- [x] Registered receivers in `AndroidManifest.xml`:
-  - [x] `DailyNotificationReceiver`
-  - [x] `BootReceiver`
-- [x] Added dependencies to `build.gradle`:
-  - [x] Room (`androidx.room:room-runtime:2.6.1`)
-  - [x] WorkManager (`androidx.work:work-runtime-ktx:2.9.0`)
-  - [x] Coroutines (`org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3`)
-  - [x] Room Compiler (`androidx.room:room-compiler:2.6.1`)
-- [x] Registered plugin in `MainActivity.java`
-
-### iOS Configuration
-- [x] Added to `Info.plist`:
-  - [x] `UIBackgroundModes` (fetch, processing)
-  - [x] `BGTaskSchedulerPermittedIdentifiers`
-  - [x] `NSUserNotificationAlertStyle`
-- [ ] ⚠️ **MANUAL STEP**: Xcode capabilities (see Phase 5)
-
-### Documentation
-- [x] Created `doc/daily-notification-plugin-integration.md`
-- [x] Created `doc/daily-notification-plugin-integration-summary.md`
-- [x] Created `doc/daily-notification-plugin-architecture.md`
-- [x] Created this checklist
-
----
-
-## Phase 2: UI Integration ⏳ TODO
-
-### Update Components
-- [ ] Modify `PushNotificationPermission.vue`:
-  - [ ] Import `NotificationService`
-  - [ ] Replace direct web push calls with service methods
-  - [ ] Add platform-aware messaging
-  - [ ] Test permission flow
-  - [ ] Test notification scheduling
-
-### Update Views
-- [ ] Update `AccountViewView.vue`:
-  - [ ] Use `NotificationService` for status checks
-  - [ ] Add platform indicator
-  - [ ] Test settings display
-  
-### Settings Integration
-- [ ] Verify settings save/load correctly:
-  - [ ] `notifyingNewActivityTime` for native
-  - [ ] `notifyingReminderMessage` for native
-  - [ ] `notifyingReminderTime` for native
-  - [ ] Existing web push settings preserved
-
----
-
-## Phase 3: Web Push Integration ⏳ TODO
-
-### Wire WebPushNotificationService
-- [ ] Extract subscription logic from `PushNotificationPermission.vue`
-- [ ] Implement `scheduleDailyNotification()` method
-- [ ] Implement `cancelDailyNotification()` method
-- [ ] Implement `getStatus()` method
-- [ ] Test web platform notification flow
-
-### Server Integration
-- [ ] Verify web push server endpoints still work
-- [ ] Test subscription/unsubscription
-- [ ] Test scheduled message delivery
-
----
-
-## Phase 4: Testing ⏳ TODO
-
-### Desktop Development
-- [ ] Code compiles without errors
-- [ ] ESLint passes
-- [ ] TypeScript types are correct
-- [ ] Platform detection works in browser console
-
-### Android Emulator
-- [ ] App builds successfully
-- [ ] Plugin loads without errors
-- [ ] Can open app and navigate
-- [ ] No JavaScript console errors
-
-### Android Device (Real)
-- [ ] Request permissions dialog appears
-- [ ] Permissions can be granted
-- [ ] Schedule notification succeeds
-- [ ] Notification appears at scheduled time
-- [ ] Notification survives app close
-- [ ] Notification survives device reboot
-- [ ] Notification can be cancelled
-
-### iOS Simulator
-- [ ] App builds successfully
-- [ ] Plugin loads without errors
-- [ ] Can open app and navigate
-- [ ] No JavaScript console errors
-
-### iOS Device (Real)
-- [ ] Request permissions dialog appears
-- [ ] Permissions can be granted
-- [ ] Schedule notification succeeds
-- [ ] Notification appears at scheduled time
-- [ ] Background fetch works
-- [ ] Notification survives app close
-- [ ] Notification can be cancelled
-
-### Web Browser
-- [ ] Existing web push still works
-- [ ] No JavaScript errors
-- [ ] Platform detection selects web service
-- [ ] Permission flow works
-- [ ] Subscription works
-
----
-
-## Phase 5: iOS Xcode Setup ⚠️ MANUAL REQUIRED
-
-### Open Xcode Project
-```bash
-cd ios
-open App/App.xcodeproj
-```
-
-### Configure Capabilities
-- [ ] Select "App" target in project navigator
-- [ ] Go to "Signing & Capabilities" tab
-- [ ] Click "+ Capability" button
-- [ ] Add "Background Modes":
-  - [ ] Enable "Background fetch"
-  - [ ] Enable "Background processing"
-- [ ] Click "+ Capability" button again
-- [ ] Add "Push Notifications" (if using remote notifications)
-
-### Install CocoaPods
-```bash
-cd ios
-pod install
-cd ..
-```
-- [ ] Run `pod install` successfully
-- [ ] Verify `CapacitorDailyNotification` pod is installed
-
-### Verify Configuration
-- [ ] Build succeeds in Xcode
-- [ ] No capability warnings
-- [ ] No pod errors
-- [ ] Can run on simulator
-
----
-
-## Phase 6: Build & Deploy ⏳ TODO
-
-### Sync Capacitor
-```bash
-npx cap sync
-```
-- [ ] Sync completes without errors
-- [ ] Plugin files copied to native projects
-
-### Build Android
-```bash
-npm run build:android:debug
-```
-- [ ] Build succeeds
-- [ ] APK/AAB generated
-- [ ] Can install on device/emulator
-
-### Build iOS
-```bash
-npm run build:ios:debug
-```
-- [ ] Build succeeds
-- [ ] IPA generated (if release)
-- [ ] Can install on device/simulator
-
-### Test Production Builds
-- [ ] Android release build works
-- [ ] iOS release build works
-- [ ] Notifications work in production
-
----
-
-## Troubleshooting Checklist
-
-### Android Issues
-
-#### Notifications Not Appearing
-- [ ] Verified `DailyNotificationReceiver` is in AndroidManifest.xml
-- [ ] Checked logcat for errors: `adb logcat | grep DailyNotification`
-- [ ] Verified permissions granted in app settings
-- [ ] Checked "Exact alarms" permission (Android 12+)
-- [ ] Verified notification channel is created
-
-#### Build Errors
-- [ ] Verified all dependencies in build.gradle
-- [ ] Ran `./gradlew clean` and rebuilt
-- [ ] Verified Kotlin version compatibility
-- [ ] Checked for conflicting dependencies
-
-### iOS Issues
-
-#### Notifications Not Appearing
-- [ ] Verified Background Modes enabled in Xcode
-- [ ] Checked Xcode console for errors
-- [ ] Verified permissions granted in Settings app
-- [ ] Tested on real device (not just simulator)
-- [ ] Checked BGTaskScheduler identifiers match Info.plist
-
-#### Build Errors
-- [ ] Ran `pod install` successfully
-- [ ] Verified deployment target is iOS 13.0+
-- [ ] Checked for pod conflicts
-- [ ] Cleaned build folder (Xcode → Product → Clean Build Folder)
-
-### Web Issues
-
-#### Web Push Not Working
-- [ ] Verified service worker is registered
-- [ ] Checked browser console for errors
-- [ ] Verified VAPID keys are correct
-- [ ] Tested in supported browser (Chrome 42+, Firefox)
-- [ ] Checked push server is running
-
-#### Permission Issues
-- [ ] Verified permissions not blocked in browser
-- [ ] Checked site settings in browser
-- [ ] Verified HTTPS connection (required for web push)
-
----
-
-## Verification Commands
-
-### Check Plugin is Installed
-```bash
-npm list @timesafari/daily-notification-plugin
-```
-
-### Check Capacitor Sync
-```bash
-npx cap ls
-```
-
-### Check Android Build
-```bash
-cd android
-./gradlew clean
-./gradlew assembleDebug
-```
-
-### Check iOS Build
-```bash
-cd ios
-pod install
-xcodebuild -workspace App/App.xcworkspace -scheme App -configuration Debug build
-```
-
-### Check TypeScript
-```bash
-npm run type-check
-```
-
-### Check Linting
-```bash
-npm run lint
-```
-
----
-
-## Next Immediate Actions
-
-1. **Run Capacitor Sync**:
-   ```bash
-   npx cap sync
-   ```
-
-2. **For iOS Development**:
-   ```bash
-   cd ios
-   open App/App.xcodeproj
-   # Enable Background Modes capability
-   pod install
-   cd ..
-   ```
-
-3. **Test on Emulator/Simulator**:
-   ```bash
-   npm run build:android:debug  # For Android
-   npm run build:ios:debug      # For iOS
-   ```
-
-4. **Update UI Components**:
-   - Start with `PushNotificationPermission.vue`
-   - Import and use `NotificationService`
-
----
-
-## Success Criteria
-
-- [x] **Phase 1**: All files created and configurations applied
-- [ ] **Phase 2**: Components use NotificationService
-- [ ] **Phase 3**: Web push integrated with service
-- [ ] **Phase 4**: All tests pass on all platforms
-- [ ] **Phase 5**: iOS capabilities configured in Xcode
-- [ ] **Phase 6**: Production builds work on real devices
-
----
-
-## Questions or Issues?
-
-See documentation:
-- Full guide: `doc/daily-notification-plugin-integration.md`
-- Architecture: `doc/daily-notification-plugin-architecture.md`
-- Summary: `doc/daily-notification-plugin-integration-summary.md`
-
-Plugin docs: `node_modules/@timesafari/daily-notification-plugin/README.md`
-
----
-
-**Current Status**: Ready for Phase 2 (UI Integration) 🚀

doc/daily-notification-plugin-integration-summary.md

@@ -1,193 +0,0 @@
-# Daily Notification Plugin Integration - Summary
-
-**Date**: 2026-01-21  
-**Status**: ✅ Phase 1 Complete  
-**Next Phase**: UI Integration
-
----
-
-## What Was Completed
-
-### ✅ Plugin Infrastructure
-1. **Plugin Registration**: `src/plugins/DailyNotificationPlugin.ts`
-   - Capacitor plugin registered with full TypeScript types
-   - Native-only (iOS/Android)
-
-2. **Service Abstraction**: `src/services/notifications/`
-   - `NotificationService.ts` - Platform detection & factory
-   - `NativeNotificationService.ts` - Native implementation
-   - `WebPushNotificationService.ts` - Web stub (for future)
-   - `index.ts` - Barrel export
-
-3. **Android Configuration**:
-   - ✅ Permissions added to `AndroidManifest.xml`
-   - ✅ Receivers registered (DailyNotificationReceiver, BootReceiver)
-   - ✅ Dependencies added to `build.gradle` (Room, WorkManager, Coroutines)
-   - ✅ Plugin registered in `MainActivity.java`
-
-4. **iOS Configuration**:
-   - ✅ Background modes added to `Info.plist`
-   - ✅ BGTaskScheduler identifiers configured
-   - ⚠️ **Requires manual Xcode setup** (capabilities)
-
-5. **Documentation**: `doc/daily-notification-plugin-integration.md`
-
----
-
-## Platform Support
-
-| Platform | Notification System | Status |
-|----------|---------------------|--------|
-| **iOS** | Native (UNUserNotificationCenter) | ✅ Configured |
-| **Android** | Native (NotificationManager + AlarmManager) | ✅ Configured |
-| **Web/PWA** | Web Push (existing) | 🔄 Coexists, not yet wired |
-| **Electron** | Native (via Capacitor) | ✅ Ready |
-
-**Key Feature**: Both systems coexist using runtime platform detection.
-
----
-
-## Quick Start Usage
-
-```typescript
-import { NotificationService } from '@/services/notifications';
-
-// Automatically uses native on iOS/Android, web push on web
-const service = NotificationService.getInstance();
-
-// Request permissions
-const granted = await service.requestPermissions();
-
-if (granted) {
-  // Schedule daily notification at 9 AM
-  await service.scheduleDailyNotification({
-    time: '09:00',
-    title: 'Daily Check-In',
-    body: 'Time to check your TimeSafari activity'
-  });
-}
-
-// Check status
-const status = await service.getStatus();
-console.log('Notifications enabled:', status.enabled);
-```
-
----
-
-## Next Steps
-
-### Immediate (Phase 2)
-1. **Update UI Components**:
-   - Modify `PushNotificationPermission.vue` to use `NotificationService`
-   - Add platform-aware messaging
-   - Test on simulator/emulator
-
-2. **iOS Xcode Setup** (Required):
-   ```bash
-   cd ios
-   open App/App.xcodeproj
-   ```
-   - Enable "Background Modes" capability
-   - Enable "Push Notifications" capability
-   - Run `pod install`
-
-### Short-term (Phase 3)
-3. **Wire Web Push**: Connect `WebPushNotificationService` to existing web push logic
-4. **Test on Devices**: Real iOS and Android devices
-5. **Update Settings**: Ensure notification preferences save correctly
-
----
-
-## Build & Sync
-
-```bash
-# Sync native projects with web code
-npx cap sync
-
-# Build for Android
-npm run build:android:debug
-
-# Build for iOS (after Xcode setup)
-cd ios && pod install && cd ..
-npm run build:ios:debug
-```
-
----
-
-## Important Notes
-
-### ⚠️ Critical Requirements
-
-**Android**:
-- `DailyNotificationReceiver` must be in AndroidManifest.xml (✅ done)
-- Runtime permissions needed for Android 13+ (API 33+)
-- Exact alarm permission for Android 12+ (API 31+)
-
-**iOS**:
-- Background Modes capability must be enabled in Xcode (⚠️ manual)
-- BGTaskScheduler identifiers must match Info.plist (✅ done)
-- Test on real device (simulators have limitations)
-
-**Web**:
-- Existing Web Push continues to work unchanged
-- No conflicts - platform detection ensures correct system
-
----
-
-## Files Created/Modified
-
-### Created (8 files)
-- `src/plugins/DailyNotificationPlugin.ts`
-- `src/services/notifications/NotificationService.ts`
-- `src/services/notifications/NativeNotificationService.ts`
-- `src/services/notifications/WebPushNotificationService.ts`
-- `src/services/notifications/index.ts`
-- `doc/daily-notification-plugin-integration.md`
-- `doc/daily-notification-plugin-integration-summary.md`
-
-### Modified (4 files)
-- `android/app/src/main/AndroidManifest.xml` - Permissions + Receivers
-- `android/app/build.gradle` - Dependencies
-- `android/app/src/main/java/app/timesafari/MainActivity.java` - Plugin registration
-- `ios/App/App/Info.plist` - Background modes + BGTaskScheduler
-
----
-
-## Testing Checklist
-
-### Before Device Testing
-- [ ] Code compiles without errors
-- [ ] Platform detection logic verified
-- [ ] Service factory creates correct implementation
-
-### Android Device
-- [ ] Request permissions (Android 13+)
-- [ ] Schedule notification
-- [ ] Notification appears at scheduled time
-- [ ] Notification survives app close
-- [ ] Notification survives device reboot
-
-### iOS Device
-- [ ] Xcode capabilities enabled
-- [ ] Request permissions
-- [ ] Schedule notification
-- [ ] Notification appears at scheduled time
-- [ ] Background fetch works
-- [ ] Notification survives app close
-
-### Web/PWA
-- [ ] Existing web push still works
-- [ ] No errors in console
-- [ ] Platform detection selects web implementation
-
----
-
-## Questions?
-
-See full documentation: `doc/daily-notification-plugin-integration.md`
-
-Plugin README: `node_modules/@timesafari/daily-notification-plugin/README.md`
-
----
-
-**Status**: Ready for Phase 2 (UI Integration) 🚀

doc/daily-notification-plugin-integration.md

@@ -1,237 +0,0 @@
-# Daily Notification Plugin Integration
-
-**Date**: 2026-01-21  
-**Status**: ✅ Phase 1 Complete - Native Infrastructure  
-**Integration Type**: Native + Web Coexistence
-
-## Overview
-
-The Daily Notification Plugin has been integrated to provide native notification functionality for iOS and Android while maintaining existing Web Push for web/PWA builds. The integration uses platform detection to automatically select the appropriate notification system at runtime.
-
-## What Was Implemented
-
-### 1. **Plugin Registration** ✅
-- **File**: `src/plugins/DailyNotificationPlugin.ts`
-- Registered Capacitor plugin with proper TypeScript types
-- Native-only (no web implementation)
-
-### 2. **Service Abstraction Layer** ✅
-Created unified notification service with platform-specific implementations:
-
-- **`NotificationService.ts`**: Factory that selects implementation based on platform
-- **`NativeNotificationService.ts`**: Wraps DailyNotificationPlugin for iOS/Android
-- **`WebPushNotificationService.ts`**: Stub for future Web Push integration
-
-**Location**: `src/services/notifications/`
-
-**Key Features**:
-- Unified interface (`NotificationServiceInterface`)
-- Automatic platform detection via `Capacitor.isNativePlatform()`
-- Type-safe implementation
-- Singleton pattern for efficiency
-
-### 3. **Android Configuration** ✅
-
-**Modified Files**:
-- `android/app/src/main/AndroidManifest.xml`
-- `android/app/build.gradle`
-- `android/app/src/main/java/app/timesafari/MainActivity.java`
-
-**Changes**:
-- ✅ Added notification permissions (POST_NOTIFICATIONS, SCHEDULE_EXACT_ALARM, etc.)
-- ✅ Registered `DailyNotificationReceiver` (critical for alarm delivery)
-- ✅ Registered `BootReceiver` (restores schedules after device restart)
-- ✅ Added Room, WorkManager, and Coroutines dependencies
-- ✅ Registered plugin in MainActivity
-
-### 4. **iOS Configuration** ✅
-
-**Modified Files**:
-- `ios/App/App/Info.plist`
-
-**Changes**:
-- ✅ Added `UIBackgroundModes` (fetch, processing)
-- ✅ Added `BGTaskSchedulerPermittedIdentifiers` for background tasks
-- ✅ Added `NSUserNotificationAlertStyle` for alert-style notifications
-
-**Still Required** (Manual in Xcode):
-- ⚠️ Enable "Background Modes" capability in Xcode
-  - Background fetch
-  - Background processing
-- ⚠️ Enable "Push Notifications" capability (if using remote notifications)
-
-## Platform Behavior
-
-| Platform | Implementation | Status |
-|----------|---------------|--------|
-| **iOS** | DailyNotificationPlugin (native) | ✅ Configured |
-| **Android** | DailyNotificationPlugin (native) | ✅ Configured |
-| **Web/PWA** | Web Push (existing) | 🔄 Not yet wired up |
-| **Electron** | Would use native | ✅ Ready |
-
-## Usage Example
-
-```typescript
-import { NotificationService } from '@/services/notifications/NotificationService';
-
-// Get the appropriate service for current platform
-const notificationService = NotificationService.getInstance();
-
-// Check platform
-console.log('Platform:', NotificationService.getPlatform());
-console.log('Is native:', NotificationService.isNative());
-
-// Request permissions
-const granted = await notificationService.requestPermissions();
-
-if (granted) {
-  // Schedule daily notification
-  await notificationService.scheduleDailyNotification({
-    time: '09:00',
-    title: 'Daily Check-In',
-    body: 'Time to check your TimeSafari activity',
-    priority: 'normal'
-  });
-}
-
-// Check status
-const status = await notificationService.getStatus();
-console.log('Enabled:', status.enabled);
-console.log('Time:', status.scheduledTime);
-```
-
-## Next Steps
-
-### Phase 2: UI Integration
-- [ ] Update `PushNotificationPermission.vue` to use `NotificationService`
-- [ ] Add platform-aware UI messaging
-- [ ] Update settings storage to work with both systems
-- [ ] Test notification scheduling UI
-
-### Phase 3: Web Push Integration
-- [ ] Wire `WebPushNotificationService` to existing PushNotificationPermission logic
-- [ ] Extract web push subscription code into service methods
-- [ ] Test web platform notification flow
-
-### Phase 4: Testing & Polish
-- [ ] Test on real iOS device
-- [ ] Test on real Android device (API 23+, API 33+)
-- [ ] Test permission flows
-- [ ] Test notification delivery
-- [ ] Test app restart/reboot scenarios
-- [ ] Verify background notification delivery
-
-### Phase 5: Xcode Configuration (iOS Only)
-- [ ] Open `ios/App/App.xcodeproj` in Xcode
-- [ ] Select App target → Signing & Capabilities
-- [ ] Click "+ Capability" → Add "Background Modes"
-  - Enable "Background fetch"
-  - Enable "Background processing"
-- [ ] Click "+ Capability" → Add "Push Notifications" (if using remote)
-- [ ] Run `pod install` in `ios/` directory
-- [ ] Build and test on device
-
-## Build Commands
-
-### Sync Capacitor
-```bash
-npx cap sync
-# or
-npx cap sync android
-npx cap sync ios
-```
-
-### Build Android
-```bash
-npm run build:android
-# or
-npm run build:android:debug
-```
-
-### Build iOS
-```bash
-npm run build:ios
-# or after Xcode setup:
-cd ios && pod install && cd ..
-npm run build:ios:debug
-```
-
-## Important Notes
-
-### Android
-- **Critical**: `DailyNotificationReceiver` must be in AndroidManifest.xml
-- Android 12+ (API 31+) requires `SCHEDULE_EXACT_ALARM` permission
-- Android 13+ (API 33+) requires runtime `POST_NOTIFICATIONS` permission
-- BootReceiver restores schedules after device restart
-
-### iOS
-- **Critical**: Background modes must be enabled in Xcode capabilities
-- iOS 13.0+ supported (already compatible with your deployment target)
-- Background tasks use `BGTaskScheduler`
-- User must grant notification permissions in Settings
-
-### Web
-- Existing Web Push continues to work
-- No conflicts with native implementation
-- Platform detection ensures correct system is used
-
-## Files Modified
-
-### Created
-- `src/plugins/DailyNotificationPlugin.ts`
-- `src/services/notifications/NotificationService.ts`
-- `src/services/notifications/NativeNotificationService.ts`
-- `src/services/notifications/WebPushNotificationService.ts`
-
-### Modified
-- `android/app/src/main/AndroidManifest.xml`
-- `android/app/build.gradle`
-- `android/app/src/main/java/app/timesafari/MainActivity.java`
-- `ios/App/App/Info.plist`
-
-## Troubleshooting
-
-### Android: Notifications Not Appearing
-1. Check that `DailyNotificationReceiver` is registered in AndroidManifest.xml
-2. Verify permissions are requested at runtime (Android 13+)
-3. Check that notification channel is created
-4. Enable "Exact alarms" in app settings (Android 12+)
-
-### iOS: Background Tasks Not Running
-1. Ensure Background Modes capability is enabled in Xcode
-2. Check that BGTaskScheduler identifiers match Info.plist
-3. Test on real device (simulator has limitations)
-4. Check iOS Settings → Notifications → TimeSafari
-
-### Permission Issues
-1. Request permissions before scheduling: `requestPermissions()`
-2. Check permission status: `checkPermissions()`
-3. Guide users to system settings if denied
-
-## Plugin Documentation
-
-For complete plugin documentation, see:
-- Plugin README: `node_modules/@timesafari/daily-notification-plugin/README.md`
-- Plugin version: 1.0.11
-- Repository: https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin
-
-## Testing Checklist
-
-- [ ] Android: Notification appears at scheduled time
-- [ ] Android: Notification survives app close
-- [ ] Android: Notification survives device reboot
-- [ ] iOS: Notification appears at scheduled time
-- [ ] iOS: Background fetch works
-- [ ] iOS: Notification survives app close
-- [ ] Web: Existing web push still works
-- [ ] Platform detection works correctly
-- [ ] Permission requests work on all platforms
-- [ ] Status retrieval works correctly
-
-## Current Status
-
-✅ **Phase 1 Complete**: Native infrastructure configured  
-🔄 **Phase 2 In Progress**: Ready for UI integration  
-⏳ **Phase 3 Pending**: Web Push service integration  
-⏳ **Phase 4 Pending**: Testing and validation  
-⏳ **Phase 5 Pending**: Xcode capabilities setup

doc/debug-hook-guide.md

@@ -80,7 +80,7 @@ installed by each developer. They are not automatically active.
 - Test files: `*.test.js`, `*.spec.ts`, `*.test.vue`
 - Scripts: `scripts/` directory
 - Test directories: `test-*` directories
-- Documentation: `doc/`, `*.md`, `*.txt`
+- Documentation: `docs/`, `*.md`, `*.txt`
 - Config files: `*.json`, `*.yml`, `*.yaml`
 - IDE files: `.cursor/` directory
 

doc/endorser-jwt-background-prefetch-options.md

@@ -1,152 +0,0 @@
-# Options: expired JWT during background “New Activity” prefetch (mobile)
-
-**Date:** 2026-03-26 17:29 PST  
-**Audience:** TimeSafari / crowd-funder team; **Endorser server** maintainers (auth + API policy)  
-**Context:** Android Capacitor app, `POST /api/v2/report/plansLastUpdatedBetween`, native `TimeSafariNativeFetcher` invoked from WorkManager at **T−5 minutes** before the daily notification.
-
----
-
-## Problem (short)
-
-New Activity notifications prefetch Endorser data in **background** (no JavaScript, no WebView). The HTTP client uses a **Bearer JWT** supplied earlier via `configureNativeFetcher` / `getHeaders(activeDid)`.
-
-If the **access token’s `exp`** is **before** prefetch time, the API returns **400** with a body like:
-
-```json
-{
-  "error": {
-    "message": "JWT failed verification: ... JWT has expired: exp: … < now: …",
-    "code": "JWT_VERIFY_FAILED"
-  }
-}
-```
-
-We **cannot** rely on the user opening the app immediately before prefetch (T−5), so **client-only** mitigations (e.g. refresh JWT on app resume) **reduce** failures but **do not guarantee** a valid token for headless background work.
-
----
-
-## Why this is different from normal in-app API calls
-
-| In-app | Background prefetch |
-|--------|----------------------|
-| `getHeaders()` runs in JS when needed; user often recently active | WorkManager runs **without** Capacitor / passkey / session refresh |
-| Short TTL tokens are refreshed as the user uses the app | Same token may sit in native memory until **T−5** (or longer) |
-
-So **server-side** and **architecture** choices matter for this feature.
-
----
-
-## Options (for decision)
-
-### 1. Increase access token TTL (Endorser / IdP)
-
-**Idea:** Issue access JWTs with a longer `exp` so that **configure time → prefetch time** (often **5+ minutes**, sometimes **24h+** if the user rarely opens the app) usually still falls inside validity.
-
-| Pros | Cons |
-|------|------|
-| Simple to explain; one policy change | Longer-lived bearer tokens increase risk if exfiltrated; mitigate with scope, rotation, monitoring |
-| No client protocol change | May not fit strict security posture without a dedicated scope |
-
-**Endorser owner:** token lifetime, scopes, and whether a **dedicated** lifetime or scope for “mobile background read” is acceptable.
-
----
-
-### 2. Scoped long-lived token for report reads only (Endorser)
-
-**Idea:** Mint a **separate** access token (or sub-scope) valid only for **read-only report** endpoints (`plansLastUpdatedBetween`, etc.), with a **longer TTL** than the interactive session token.
-
-| Pros | Cons |
-|------|------|
-| Limits blast radius vs “longer JWT for everything” | Requires auth model + issuance path; client must store/use this token only for prefetch |
-
-**Endorser owner:** feasibility of **narrow scope** + **longer TTL** for this use case.
-
----
-
-### 3. Refresh token or device grant (Endorser + mobile native)
-
-**Idea:** Client stores a **refresh token** (or OAuth **device** grant) in **Android Keystore / iOS Keychain**. Before `plansLastUpdatedBetween`, **native** code (no JS) exchanges it for a **new access token**.
-
-| Pros | Cons |
-|------|------|
-| Standard pattern; short TTL for access tokens remains | Endorser must support refresh (or equivalent); secure storage + rotation; **both** client and server work |
-| Works when app is backgrounded for days | Implementation cost on mobile |
-
-**Endorser owner:** refresh endpoint, token rotation, revocation.  
-**Mobile owner:** native fetch path, secure storage, failure handling.
-
----
-
-### 4. Backend proxy / BFF (TimeSafari backend + Endorser)
-
-**Idea:** Phone calls **your** backend with a **device session** (or FCM registration id); **server** uses **server-to-server** credentials or a **service account** to call Endorser. The device **never** sends an Endorser JWT for this path.
-
-| Pros | Cons |
-|------|------|
-| No Endorser JWT lifetime problem on device | New service, auth, rate limits, privacy review |
-| Central place for logging, abuse control | Operational cost |
-
-**Endorser owner:** partner / S2S auth model for the BFF.  
-**Product team:** hosting and trust boundaries.
-
----
-
-### 5. “Cron” or periodic jobs on the device to refresh JWT (JS)
-
-**Idea:** Use something like a **cron** schedule to refresh tokens.
-
-**Reality:** Scheduled **native** jobs can run, but **Capacitor / `getHeaders()` / passkey** do **not** run reliably in that context without waking the **WebView**. So **“cron”** only helps if refresh is **fully native** (see option 3) or you accept **unreliable** wake + JS.
-
-**Not recommended** as the primary fix unless paired with **native refresh** or **server** changes.
-
----
-
-### 6. Product / UX constraints (no server change)
-
-**Idea:** Accept that **headless** API calls may fail if the session is stale; show **fallback** copy; or require “open app once per day” for best results.
-
-| Pros | Cons |
-|------|------|
-| No Endorser change | Does not meet “API-driven notification” expectation for inactive users |
-
----
-
-## Client-side mitigations already in play (not sufficient alone)
-
-- **`configureNativeFetcherIfReady()`** after startup and when **Account** / identity is ready.
-- **`appStateChange` → `isActive`:** refresh native fetcher when the app returns to foreground (reduces staleness when the user **does** open the app).
-- **Error logging** of 400 bodies for diagnosis.
-
-These **do not** guarantee a fresh JWT at **T−5** if the user never opens the app before prefetch.
-
----
-
-## Suggested decision order
-
-1. **Align on security posture:** Is a **longer TTL** or **scoped long-lived read token** acceptable for Endorser?
-2. If not, is **refresh token in native** (option 3) or **BFF** (option 4) on the roadmap?
-3. **Parallel:** UX fallback when API is unavailable (option 6) so the app never silently looks “broken.”
-
----
-
-## References (this repo)
-
-| Topic | Location |
-|--------|----------|
-| Native fetcher + JWT from `getHeaders` | `src/services/notifications/nativeFetcherConfig.ts` |
-| Android POST + errors | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
-| Web `plansLastUpdatedBetween` + `afterId` | `src/libs/endorserServer.ts` (`getStarredProjectsWithChanges`) |
-| New Activity / dual schedule | `doc/notification-from-api-call.md`, `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` |
-
----
-
-## Open questions for Endorser (server developer)
-
-1. What is the **current access token TTL** and can it be **increased** for mobile clients, or **per-scope**?
-2. Is **refresh token** (or similar) available for **non-interactive** renewal?
-3. Would a **read-only** scope for `plansLastUpdatedBetween` with a **longer** lifetime be acceptable?
-4. Is there an existing **server-to-server** or **partner** path that a **BFF** could use instead of user JWT on device?
-
----
-
-*This document is for internal planning and decision; update it when the team chooses an approach.*

doc/error-diagnostics-log.md

@@ -92,5 +92,5 @@ Multiple stack traces showing Vue router navigation and component mounting cycle
 3. Address API/server issues in separate debugging session
 
 ---
-*Log Entry by: Migration Assistant*  
-*Session: ProjectsView.vue Triple Migration Pattern*
+_Log Entry by: Migration Assistant_  
+_Session: ProjectsView.vue Triple Migration Pattern_

doc/ios-share-extension-git-commit-guide.md

@@ -1,139 +0,0 @@
-# iOS Share Extension - Git Commit Guide
-
-**Date:** 2025-01-27  
-**Purpose:** Clarify which Xcode manual changes should be committed to the repository
-
-## Quick Answer
-
-**YES, most manual Xcode changes SHOULD be committed.** The only exceptions are user-specific settings that are already gitignored.
-
-## What Gets Modified (and Should Be Committed)
-
-When you create the Share Extension target and configure App Groups in Xcode, the following files are modified:
-
-### 1. `ios/App/App.xcodeproj/project.pbxproj` ✅ **COMMIT THIS**
-
-This is the main Xcode project file that tracks:
-- **New targets** (Share Extension target)
-- **File references** (which files belong to which targets)
-- **Build settings** (compiler flags, deployment targets, etc.)
-- **Build phases** (compile sources, link frameworks, etc.)
-- **Capabilities** (App Groups configuration)
-- **Target dependencies**
-
-**This file IS tracked in git** (not in `.gitignore`), so changes should be committed.
-
-### 2. Entitlements Files ✅ **COMMIT THESE**
-
-When you enable App Groups capability, Xcode creates/modifies:
-- `ios/App/App/App.entitlements` (for main app)
-- `ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements` (for extension)
-
-These files contain the App Group identifiers and should be committed.
-
-### 3. Share Extension Source Files ✅ **ALREADY COMMITTED**
-
-The following files are already in the repo:
-- `ios/App/TimeSafariShareExtension/ShareViewController.swift`
-- `ios/App/TimeSafariShareExtension/Info.plist`
-- `ios/App/App/ShareImageBridge.swift`
-
-These should already be committed (they were created as part of the implementation).
-
-## What Should NOT Be Committed
-
-### 1. User-Specific Settings ❌ **ALREADY GITIGNORED**
-
-These are in `ios/.gitignore`:
-- `xcuserdata/` - User-specific scheme selections, breakpoints, etc.
-- `*.xcuserstate` - User's current Xcode state
-
-### 2. Signing Identities ❌ **USER-SPECIFIC**
-
-While the **App Groups capability** should be committed (it's in `project.pbxproj` and entitlements), your **personal signing identity/team** is user-specific and Xcode handles this automatically per developer.
-
-## What Happens When You Commit
-
-When you commit the changes:
-
-1. **Other developers** who pull the changes will:
-   - ✅ Get the new Share Extension target automatically
-   - ✅ Get the App Groups capability configuration
-   - ✅ Get file references and build settings
-   - ✅ See the Share Extension in their Xcode project
-
-2. **They will still need to:**
-   - Configure their own signing team/identity (Xcode prompts for this)
-   - Build the project (which may trigger CocoaPods updates)
-   - But they **won't** need to manually create the target or configure App Groups
-
-## Step-by-Step: What to Commit
-
-After completing the Xcode setup steps:
-
-```bash
-# Check what changed
-git status
-
-# You should see:
-# - ios/App/App.xcodeproj/project.pbxproj (modified)
-# - ios/App/App/App.entitlements (new or modified)
-# - ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements (new)
-# - Possibly other project-related files
-
-# Review the changes
-git diff ios/App/App.xcodeproj/project.pbxproj
-
-# Commit the changes
-git add ios/App/App.xcodeproj/project.pbxproj
-git add ios/App/App/App.entitlements
-git add ios/App/TimeSafariShareExtension/TimeSafariShareExtension.entitlements
-git commit -m "Add iOS Share Extension target and App Groups configuration"
-```
-
-## Important Notes
-
-### Merge Conflicts in project.pbxproj
-
-The `project.pbxproj` file can have merge conflicts because:
-- It's auto-generated by Xcode
-- Multiple developers might modify it
-- It uses UUIDs that can conflict
-
-**If you get merge conflicts:**
-1. Open the project in Xcode
-2. Xcode will often auto-resolve conflicts
-3. Or manually resolve by keeping both sets of changes
-4. Test that the project builds
-
-### Team/Developer IDs
-
-The `DEVELOPMENT_TEAM` setting in `project.pbxproj` might be user-specific:
-- Some teams commit this (if everyone uses the same team)
-- Some teams use `.xcconfig` files to override per developer
-- Check with your team's practices
-
-If you see `DEVELOPMENT_TEAM = GM3FS5JQPH;` in the project file, this is already committed, so your team likely commits team IDs.
-
-## Verification
-
-After committing, verify that:
-1. The Share Extension target appears in Xcode for other developers
-2. App Groups capability is configured
-3. The project builds successfully
-4. No user-specific files were accidentally committed
-
-## Summary
-
-| Change Type | Commit? | Reason |
-|------------|---------|--------|
-| New target creation | ✅ Yes | Modifies `project.pbxproj` |
-| App Groups capability | ✅ Yes | Creates/modifies entitlements files |
-| File target membership | ✅ Yes | Modifies `project.pbxproj` |
-| Build settings | ✅ Yes | Modifies `project.pbxproj` |
-| Source files (Swift, plist) | ✅ Yes | Already in repo |
-| User scheme selections | ❌ No | In `xcuserdata/` (gitignored) |
-| Personal signing identity | ⚠️ Maybe | Depends on team practice |
-
-**Bottom line:** Commit all the Xcode project configuration changes. Other developers will get the Share Extension target automatically when they pull, and they'll only need to configure their personal signing settings.
-

doc/ios-share-extension-improvements.md

@@ -1,283 +0,0 @@
-# iOS Share Extension Improvements
-
-**Date:** 2025-11-24  
-**Purpose:** Explore alternatives to improve user experience by eliminating interstitial UI and simplifying app launch mechanism
-
-## Current Implementation Issues
-
-1. **Interstitial UI**: Users see `SLComposeServiceViewController` with a "Post" button before the app opens
-2. **Deep Link Dependency**: App relies on deep link (`timesafari://shared-photo`) to detect shared images, even though data is already in App Group
-
-## Improvement 1: Skip Interstitial UI
-
-### Current Approach
-- Uses `SLComposeServiceViewController` which shows a UI with "Post" button
-- User must tap "Post" to proceed
-
-### Alternative: Custom UIViewController (Headless Processing)
-
-Replace `SLComposeServiceViewController` with a custom `UIViewController` that:
-- Processes the image immediately in `viewDidLoad`
-- Shows no UI (or minimal loading indicator)
-- Opens the app automatically
-
-**Implementation:**
-
-```swift
-import UIKit
-import UniformTypeIdentifiers
-
-class ShareViewController: UIViewController {
-    
-    private let appGroupIdentifier = "group.app.timesafari.share"
-    private let sharedPhotoBase64Key = "sharedPhotoBase64"
-    private let sharedPhotoFileNameKey = "sharedPhotoFileName"
-    
-    override func viewDidLoad() {
-        super.viewDidLoad()
-        
-        // Process image immediately without showing UI
-        processAndOpenApp()
-    }
-    
-    private func processAndOpenApp() {
-        guard let extensionContext = extensionContext,
-              let inputItems = extensionContext.inputItems as? [NSExtensionItem] else {
-            extensionContext?.completeRequest(returningItems: [], completionHandler: nil)
-            return
-        }
-        
-        processSharedImage(from: inputItems) { [weak self] success in
-            guard let self = self else {
-                self?.extensionContext?.completeRequest(returningItems: [], completionHandler: nil)
-                return
-            }
-            
-            if success {
-                self.openMainApp()
-            }
-            
-            // Complete immediately - no UI shown
-            self.extensionContext?.completeRequest(returningItems: [], completionHandler: nil)
-        }
-    }
-    
-    private func processSharedImage(from items: [NSExtensionItem], completion: @escaping (Bool) -> Void) {
-        // ... (same implementation as current)
-    }
-    
-    private func openMainApp() {
-        guard let url = URL(string: "timesafari://shared-photo") else {
-            return
-        }
-        
-        var responder: UIResponder? = self
-        while responder != nil {
-            if let application = responder as? UIApplication {
-                application.open(url, options: [:], completionHandler: nil)
-                return
-            }
-            responder = responder?.next
-        }
-        
-        extensionContext?.open(url, completionHandler: nil)
-    }
-}
-```
-
-**Info.plist Changes:**
-- Already configured correctly with `NSExtensionPrincipalClass`
-- No storyboard needed (already removed)
-
-**Benefits:**
-- ✅ No interstitial UI - app opens immediately
-- ✅ Faster user experience
-- ✅ More seamless integration
-
-**Considerations:**
-- ⚠️ User has less control (can't cancel easily)
-- ⚠️ No visual feedback during processing (could add minimal loading indicator)
-- ⚠️ Apple guidelines: Extensions should provide value even if they don't open the app
-
-## Improvement 2: Direct App Launch Without Deep Link
-
-### Current Approach
-- Share Extension stores data in App Group UserDefaults
-- Share Extension opens app via deep link (`timesafari://shared-photo`)
-- App receives deep link → checks App Group → processes image
-
-### Alternative: App Lifecycle Detection
-
-Instead of using deep links, the app can check for shared data when it becomes active:
-
-**Option A: Check on App Activation**
-
-```swift
-// In AppDelegate.swift
-func applicationDidBecomeActive(_ application: UIApplication) {
-    // Check for shared image from Share Extension
-    if let sharedData = getSharedImageData() {
-        // Store in temp file for JS to read
-        writeSharedImageToTempFile(sharedData)
-        
-        // Navigate to shared-photo route directly
-        // This would need to be handled in JS layer
-    }
-}
-```
-
-**Option B: Use Notification (More Reliable)**
-
-```swift
-// In ShareViewController.swift (after storing data)
-private func openMainApp() {
-    // Store a flag that image is ready
-    guard let userDefaults = UserDefaults(suiteName: appGroupIdentifier) else {
-        return
-    }
-    userDefaults.set(true, forKey: "sharedPhotoReady")
-    userDefaults.synchronize()
-    
-    // Open app (can use any URL scheme or even just launch the app)
-    guard let url = URL(string: "timesafari://") else {
-        return
-    }
-    
-    var responder: UIResponder? = self
-    while responder != nil {
-        if let application = responder as? UIApplication {
-            application.open(url, options: [:], completionHandler: nil)
-            return
-        }
-        responder = responder?.next
-    }
-}
-
-// In AppDelegate.swift
-func applicationDidBecomeActive(_ application: UIApplication) {
-    let appGroupIdentifier = "group.app.timesafari.share"
-    guard let userDefaults = UserDefaults(suiteName: appGroupIdentifier) else {
-        return
-    }
-    
-    // Check if shared photo is ready
-    if userDefaults.bool(forKey: "sharedPhotoReady") {
-        userDefaults.removeObject(forKey: "sharedPhotoReady")
-        userDefaults.synchronize()
-        
-        // Process shared image
-        if let sharedData = getSharedImageData() {
-            writeSharedImageToTempFile(sharedData)
-            
-            // Trigger JS to check for shared image
-            // This could be done via Capacitor App plugin or custom event
-        }
-    }
-}
-```
-
-**Option C: Check on App Launch (Most Direct)**
-
-```swift
-// In AppDelegate.swift
-func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
-    // Check for shared image immediately on launch
-    checkForSharedImageOnLaunch()
-    
-    return true
-}
-
-func applicationDidBecomeActive(_ application: UIApplication) {
-    // Also check when app becomes active (in case it was already running)
-    checkForSharedImageOnLaunch()
-}
-
-private func checkForSharedImageOnLaunch() {
-    if let sharedData = getSharedImageData() {
-        writeSharedImageToTempFile(sharedData)
-        
-        // Post a notification or use Capacitor to notify JS
-        NotificationCenter.default.post(name: NSNotification.Name("SharedPhotoReady"), object: nil)
-    }
-}
-```
-
-**JavaScript Integration:**
-
-```typescript
-// In main.capacitor.ts
-import { App } from '@capacitor/app';
-
-// Listen for app becoming active
-App.addListener('appStateChange', async ({ isActive }) => {
-  if (isActive) {
-    // Check for shared image when app becomes active
-    await checkAndStoreNativeSharedImage();
-  }
-});
-
-// Also check on initial load
-if (Capacitor.isNativePlatform() && Capacitor.getPlatform() === 'ios') {
-  checkAndStoreNativeSharedImage().then(result => {
-    if (result.success) {
-      // Navigate to shared-photo route
-      router.push('/shared-photo' + (result.fileName ? `?fileName=${result.fileName}` : ''));
-    }
-  });
-}
-```
-
-**Benefits:**
-- ✅ No deep link routing needed
-- ✅ More direct data flow
-- ✅ App can detect shared content even if it was already running
-- ✅ Simpler URL scheme handling
-
-**Considerations:**
-- ⚠️ Need to ensure app checks on both launch and activation
-- ⚠️ May need to handle race conditions (app launching vs. share extension writing)
-- ⚠️ Still need some way to open the app (minimal URL scheme still required)
-
-## Recommended Approach
-
-**Best of Both Worlds:**
-
-1. **Use Custom UIViewController** (Improvement 1) - Eliminates interstitial UI
-2. **Use App Lifecycle Detection** (Improvement 2, Option C) - Direct data flow
-
-**Combined Implementation:**
-
-```swift
-// ShareViewController.swift - Custom UIViewController
-class ShareViewController: UIViewController {
-    // Process immediately in viewDidLoad
-    // Store data in App Group
-    // Open app with minimal URL (just "timesafari://")
-}
-
-// AppDelegate.swift
-func applicationDidBecomeActive(_ application: UIApplication) {
-    // Check for shared image
-    // If found, write to temp file and let JS handle navigation
-}
-```
-
-**JavaScript:**
-```typescript
-// Check on app activation
-App.addListener('appStateChange', async ({ isActive }) => {
-  if (isActive) {
-    const result = await checkAndStoreNativeSharedImage();
-    if (result.success) {
-      router.push('/shared-photo' + (result.fileName ? `?fileName=${result.fileName}` : ''));
-    }
-  }
-});
-```
-
-This approach:
-- ✅ No interstitial UI
-- ✅ No deep link routing complexity
-- ✅ Direct data flow via App Group
-- ✅ Works whether app is running or launching fresh
-

doc/ios-share-extension-setup.md

@@ -1,140 +0,0 @@
-# iOS Share Extension Setup Instructions
-
-**Date:** 2025-01-27  
-**Purpose:** Step-by-step instructions for setting up the iOS Share Extension in Xcode
-
-## Prerequisites
-
-- Xcode installed
-- iOS project already set up with Capacitor
-- Access to Apple Developer account (for App Groups)
-
-## Step 1: Create Share Extension Target
-
-1. Open `ios/App/App.xcodeproj` in Xcode
-2. In the Project Navigator, select the **App** project (top-level item)
-3. Click the **+** button at the bottom of the Targets list
-4. Select **iOS** → **Share Extension**
-5. Click **Next**
-6. Configure:
-   - **Product Name:** `TimeSafariShareExtension`
-   - **Bundle Identifier:** `app.timesafari.shareextension` (must match main app's bundle ID with `.shareextension` suffix)
-   - **Language:** Swift
-7. Click **Finish**
-
-## Step 2: Configure Share Extension Files
-
-The following files have been created in `ios/App/TimeSafariShareExtension/`:
-
-- `ShareViewController.swift` - Main extension logic
-- `Info.plist` - Extension configuration
-
-**Verify these files exist and are added to the Share Extension target.**
-
-## Step 3: Configure App Groups
-
-App Groups allow the Share Extension and main app to share data.
-
-### For Main App Target:
-
-1. Select the **App** target in Xcode
-2. Go to **Signing & Capabilities** tab
-3. Click **+ Capability**
-4. Select **App Groups**
-5. Click **+** to add a new group
-6. Enter: `group.app.timesafari.share`
-7. Ensure it's checked/enabled
-
-### For Share Extension Target:
-
-1. Select the **TimeSafariShareExtension** target
-2. Go to **Signing & Capabilities** tab
-3. Click **+ Capability**
-4. Select **App Groups**
-5. Click **+** to add a new group
-6. Enter: `group.app.timesafari.share` (same as main app)
-7. Ensure it's checked/enabled
-
-**Important:** Both targets must use the **exact same** App Group identifier.
-
-## Step 4: Configure Share Extension Info.plist
-
-The `Info.plist` file should already be configured, but verify:
-
-1. Select `TimeSafariShareExtension/Info.plist` in Xcode
-2. Ensure it contains:
-   - `NSExtensionPointIdentifier` = `com.apple.share-services`
-   - `NSExtensionPrincipalClass` = `$(PRODUCT_MODULE_NAME).ShareViewController`
-   - `NSExtensionActivationSupportsImageWithMaxCount` = `1`
-
-## Step 5: Add ShareImageBridge to Main App
-
-1. The file `ios/App/App/ShareImageBridge.swift` has been created
-2. Ensure it's added to the **App** target (not the Share Extension target)
-3. In Xcode, select the file and check the **Target Membership** in the File Inspector
-
-## Step 6: Build and Test
-
-1. Select the **App** scheme (not the Share Extension scheme)
-2. Build and run on a device or simulator
-3. Open Photos app
-4. Select an image
-5. Tap **Share** button
-6. Look for **TimeSafari Share** in the share sheet
-7. Select it
-8. The app should open and navigate to the shared photo view
-
-## Step 7: Troubleshooting
-
-### Share Extension doesn't appear in share sheet
-
-- Verify the Share Extension target builds successfully
-- Check that `Info.plist` is correctly configured
-- Ensure the extension's bundle identifier follows the pattern: `{main-app-bundle-id}.shareextension`
-- Clean build folder (Product → Clean Build Folder)
-
-### App Group access fails
-
-- Verify both targets have the same App Group identifier
-- Check that App Groups capability is enabled for both targets
-- Ensure you're signed in with a valid Apple Developer account
-- For development, you may need to enable App Groups in your Apple Developer account
-
-### Shared image not appearing
-
-- Check Xcode console for errors
-- Verify `ShareViewController.swift` is correctly implemented
-- Ensure the deep link `timesafari://shared-photo` is being handled
-- Check that the native bridge method is being called
-
-### Build errors
-
-- Ensure Swift version matches between targets
-- Check that all required frameworks are linked
-- Verify deployment targets match between main app and extension
-
-## Step 8: Native Bridge Implementation (TODO)
-
-Currently, the JavaScript code needs a way to call the native `getSharedImageData()` method. This requires one of:
-
-1. **Option A:** Create a minimal Capacitor plugin
-2. **Option B:** Use Capacitor's existing bridge mechanisms
-3. **Option C:** Expose the method via a custom URL scheme parameter
-
-The current implementation in `main.capacitor.ts` has a placeholder that needs to be completed.
-
-## Next Steps
-
-After the Share Extension is set up and working:
-
-1. Complete the native bridge implementation to read from App Group
-2. Test end-to-end flow: Share image → Extension stores → App reads → Displays
-3. Implement Android version
-4. Add error handling and edge cases
-
-## References
-
-- [Apple Share Extensions Documentation](https://developer.apple.com/documentation/social)
-- [App Groups Documentation](https://developer.apple.com/documentation/xcode/configuring-app-groups)
-- [Capacitor Native Bridge](https://capacitorjs.com/docs/guides/building-plugins)
-

doc/ios-share-implementation-status.md

@@ -1,93 +0,0 @@
-# iOS Share Extension Implementation Status
-
-**Date:** 2025-01-27  
-**Status:** In Progress - Native Code Complete, Bridge Pending
-
-## Completed
-
-✅ **Share Extension Files Created:**
-- `ios/App/TimeSafariShareExtension/ShareViewController.swift` - Handles image sharing
-- `ios/App/TimeSafariShareExtension/Info.plist` - Extension configuration
-
-✅ **Native Bridge Created:**
-- `ios/App/App/ShareImageBridge.swift` - Native method to read from App Group
-
-✅ **JavaScript Integration Started:**
-- `src/services/nativeShareHandler.ts` - Service to handle native shared images
-- `src/main.capacitor.ts` - Updated to check for native shared images on deep link
-
-✅ **Documentation:**
-- `doc/native-share-target-implementation.md` - Complete implementation guide
-- `doc/ios-share-extension-setup.md` - Xcode setup instructions
-
-## Pending
-
-⚠️ **Xcode Configuration (Manual Steps Required):**
-1. Create Share Extension target in Xcode
-2. Configure App Groups for both main app and extension
-3. Add ShareImageBridge.swift to App target
-4. Build and test
-
-⚠️ **JavaScript-Native Bridge:**
-The current implementation has a placeholder for calling the native `ShareImageBridge.getSharedImageData()` method from JavaScript. This needs to be completed using one of:
-
-**Option A: Minimal Capacitor Plugin** (Recommended for Option 1)
-- Create a small plugin that exposes the method
-- Clean and maintainable
-- Follows Capacitor patterns
-
-**Option B: Direct Bridge Call**
-- Use Capacitor's executePlugin or similar mechanism
-- Requires understanding Capacitor's internal bridge
-- Less maintainable
-
-**Option C: AppDelegate Integration**
-- Have AppDelegate check on launch and expose via a different mechanism
-- Workaround approach
-- Less clean but functional
-
-## Next Steps
-
-1. **Complete Xcode Setup:**
-   - Follow `doc/ios-share-extension-setup.md`
-   - Create Share Extension target
-   - Configure App Groups
-   - Build and verify extension appears in share sheet
-
-2. **Implement JavaScript-Native Bridge:**
-   - Choose one of the options above
-   - Complete the `checkAndStoreNativeSharedImage()` function in `main.capacitor.ts`
-   - Test end-to-end flow
-
-3. **Testing:**
-   - Share image from Photos app
-   - Verify Share Extension appears
-   - Verify app opens and displays shared image
-   - Test "Record Gift" and "Save as Profile" flows
-
-## Current Flow
-
-1. ✅ User shares image → Share Extension receives
-2. ✅ Share Extension converts to base64
-3. ✅ Share Extension stores in App Group UserDefaults
-4. ✅ Share Extension opens app with `timesafari://shared-photo?fileName=...`
-5. ⚠️ App receives deep link (handled)
-6. ⚠️ App checks App Group UserDefaults (bridge needed)
-7. ⚠️ App stores in temp database (pending bridge)
-8. ✅ SharedPhotoView reads from temp database (already works)
-
-## Code Locations
-
-- **Share Extension:** `ios/App/TimeSafariShareExtension/`
-- **Native Bridge:** `ios/App/App/ShareImageBridge.swift`
-- **JavaScript Handler:** `src/services/nativeShareHandler.ts`
-- **Deep Link Integration:** `src/main.capacitor.ts`
-- **View Component:** `src/views/SharedPhotoView.vue` (already complete)
-
-## Notes
-
-- The Share Extension code is complete and ready to use
-- The main missing piece is the JavaScript-to-native bridge
-- Once the bridge is complete, the entire flow should work end-to-end
-- The existing `SharedPhotoView.vue` doesn't need changes - it already handles images from temp storage
-

doc/local-android-testing-analysis.md

@@ -1,401 +0,0 @@
-# Android Local Notification Testing — Planning Analysis
-
-**Created:** 2026-06-02  
-**Source document:** [local-ios-testing-ngrok.md](./local-ios-testing-ngrok.md)  
-**Purpose:** Plan a future **Android** counterpart guide by mapping what can be reused from the iOS ngrok workflow and what must be written for Android-specific push, permissions, and OS behavior.
-
-**Status:** Planning only — does not replace or modify the iOS guide.
-
----
-
-## Executive summary
-
-The iOS guide’s **backend + ngrok + in-app debug panel** path is platform-agnostic. Most of sections **1–3**, **6**, **9** (with log tooling swapped), **10** (with `platform: "android"`), **12**, and parts of **11** can be copied or lightly edited.
-
-Everything involving **APNs, Xcode, Apple Developer, iOS capabilities, and iOS background/silent-push caveats** must be replaced. Android adds **direct FCM delivery** (no APNs hop), **`google-services.json`**, **runtime notification permissions (API 33+)**, **Doze / battery optimization / OEM restrictions**, and different **force-stop / background** semantics.
-
-Existing related docs to cross-link (not duplicate):
-
-- [android-physical-device-guide.md](./android-physical-device-guide.md) — USB, `adb`, build/run commands
-- [notification-system-overview.md](./notification-system-overview.md)
-- [notification-from-api-call.md](./notification-from-api-call.md)
-- [notification-permissions-and-rollovers.md](./notification-permissions-and-rollovers.md)
-
----
-
-## iOS guide structure (reference map)
-
-| § | iOS doc heading | Reuse for Android |
-|---|-----------------|-------------------|
-| Intro | Architecture overview | **Adapt** — swap APNs leg for FCM→device |
-| — | Prerequisites | **Partial** — drop Xcode/APNs; add Android SDK/device |
-| 1 | Install and configure ngrok | **Reuse unchanged** |
-| 2 | Start the backend locally | **Reuse unchanged** |
-| 3 | Obtain and use ngrok HTTPS URL | **Reuse** — wording: “device” not “iPhone” |
-| 4 | Generate and open iOS workspace | **Rewrite** — Android Studio / Capacitor sync |
-| 5 | Firebase + APNs setup | **Rewrite** — Firebase Android only; no APNs |
-| 6 | Notification Debug Panel override | **Reuse unchanged** |
-| 7 | Firebase and Xcode checklist | **Rewrite** — Android manifest / Gradle checklist |
-| 8 | iOS-specific testing notes | **Rewrite** — Android delivery caveats |
-| 9 | Recommended debug workflow | **Reuse** — replace Xcode console with logcat |
-| 10 | Sample curl commands | **Reuse** — change `platform` to `android` |
-| 11 | Troubleshooting | **Partial** — keep ngrok/API rows; replace push rows |
-| 12 | Key source files | **Reuse unchanged** |
-| 13 | Related docs | **Extend** — link Android build/device guides |
-
----
-
-## Sections reusable unchanged (or near-unchanged)
-
-These blocks can be carried into `doc/local-android-testing-ngrok.md` (proposed name) with at most global find-replace (“iPhone” → “Android device”, “Mac” tunnel audience unchanged).
-
-### notification-wakeup-service startup (iOS §1 Terminal A, §2)
-
-- Clone **notification-wakeup-service**, `npm install`, `.env` from `.env.example`
-- `export PORT=3000` (or port from that repo’s README)
-- `npm run dev`
-- Local verify: `curl -sS http://localhost:3000/health`
-- Firebase **Admin** service account for the backend (`GOOGLE_APPLICATION_CREDENTIALS`) — same project can serve iOS and Android apps
-
-### ngrok setup (iOS §1)
-
-- `brew install ngrok/ngrok/ngrok` (or download)
-- `ngrok http 3000` in a second terminal
-- Use **HTTPS** forwarding URL; free tier URL rotation note
-- ngrok inspect UI at `http://127.0.0.1:4040`
-
-### ngrok account creation (iOS §1 “Account and auth token”)
-
-- Sign up at dashboard.ngrok.com
-- `ngrok config add-authtoken YOUR_AUTHTOKEN_HERE`
-
-### Obtaining HTTPS URL (iOS §3)
-
-- Copy `https://….ngrok-free.app` from Forwarding line
-- No trailing slash in debug panel
-- Mac-side tunnel test: `export NGROK_URL=…` and `curl "$NGROK_URL/health"`
-
-### Backend override configuration (iOS §6)
-
-- Non-production build required for Notification Debug Panel
-- Account → **Show All General Advanced Functions** → `/dev/notifications`
-- **Notification Backend URL**, **Save Backend URL**
-- `localStorage`: `notificationDebug.backendBaseUrl`, `notificationDebug.testMode`, `notificationDebug.bypassAuth`
-- Optional programmatic override via `@/services/notifications` (`setBackendBaseUrl`, `setTestMode`, `setBypassAuth`, `getNotificationApiBaseUrl`)
-
-### Debug panel usage (iOS §6 table, §8 “Two Simulate WAKEUP_PING buttons”)
-
-| Control | Android relevance |
-|---------|-------------------|
-| Notification Backend URL | Same |
-| Test Mode | Same (`testMode` in JSON body) |
-| Skip JWT Authentication | Same — explicit opt-in for unauthenticated local backends (default off) |
-| Register Token Now | Same (`POST /notifications/register`) |
-| Refresh Notifications | Same |
-| Simulate WAKEUP_PING (backend) | Same — isolates ngrok + refresh without FCM |
-| Wakeup Ping Simulator | Same — exercises `handleCapacitorPushNotificationReceived` path |
-| Event Log `[Notifications]` | Same |
-| Pending Notification Inspector | Same concept; confirm Android plugin inspector behavior in **daily-notification-plugin** |
-
-### testMode usage (iOS §6, §10)
-
-- Default-on when unset in storage (`NotificationDebugConfig.ts`)
-- Sent on register and refresh payloads
-- Backend/debug endpoints accept `testMode: true` for dev traffic
-
-### Refresh endpoint testing (iOS §9 steps 5, §11 “Refresh endpoint unreachable”)
-
-- Panel **Refresh Notifications** → expect Event Log + ngrok `POST /notifications/refresh`
-- **Simulate WAKEUP_PING** (backend button) for API-only path
-- Troubleshooting table for network error, 404, wrong port, stale URL
-
-### curl examples (iOS §10)
-
-Reuse structure; **only payload deltas** for Android doc:
-
-```bash
-export BASE="https://abc123.ngrok-free.app"
-```
-
-- `$BASE/health` — unchanged
-- `$BASE/notifications/register` — set `"platform": "android"`
-- `$BASE/notifications/refresh` — set `"platform": "android"`
-- `$BASE/debug/send-wakeup` — unchanged shape; confirm deviceId/token contract in **notification-wakeup-service** README
-
-App still uses `Capacitor.getPlatform()` for `platform` in `NotificationService.ts` (`ios` | `android`).
-
-### Shared architecture concepts (intro + silent wake sequence)
-
-Reusable narrative (edit diagram only):
-
-1. FCM **data** message with `data.type = "WAKEUP_PING"`
-2. Capacitor `pushNotificationReceived` → `handleCapacitorPushNotificationReceived()`
-3. `POST {backend}/notifications/refresh` with `testMode`
-4. `nextNotifications` → `applyNotificationRefreshPayload()` → **daily-notification-plugin** clear + schedule
-
-Repos table (notification-wakeup-service, crowd-funder-for-time-pwa, daily-notification-plugin) — unchanged.
-
-### Key source files (iOS §12)
-
-Same files apply on Android Capacitor builds:
-
-- `NotificationDebugConfig.ts`, `NotificationDebugEvents.ts`, `notificationLog.ts`
-- `NotificationService.ts`, `NativeNotificationService.ts`
-- `firebaseMessagingClient.ts`, `NotificationDebugPanel.vue`, `main.capacitor.ts`
-
-### Recommended debug workflow (iOS §9) — reuse with tooling swap
-
-Steps 1–5, 8–9 unchanged. Replace step 7:
-
-- **iOS:** Xcode console → `[Notifications] pushNotificationReceived type=WAKEUP_PING`
-- **Android:** `adb logcat` filtered on app tag / `[Notifications]` (document exact filter in Android guide)
-
----
-
-## iOS-specific sections — must rewrite for Android
-
-### Architecture diagram (intro)
-
-**iOS today:** Mac → ngrok → app; FCM → **APNs** → iPhone.
-
-**Android doc:** FCM → **device directly** (no APNs). Update ASCII diagram and caption (“silent push” on Android is still FCM data; delivery rules differ).
-
-### Prerequisites (intro list)
-
-| iOS prerequisite | Android replacement |
-|------------------|---------------------|
-| Mac with **Xcode** | **Android Studio**, JDK 17+, `ANDROID_HOME`, `adb` — see [android-physical-device-guide.md](./android-physical-device-guide.md) |
-| Physical **iPhone** | Physical **Android** device (emulator possible for some steps but **not** representative for Doze/OEM/battery) |
-| Firebase with **APNs** for bundle ID | Firebase with **Android app** (`app.timesafari` package name) |
-| Non-production build | Same — e.g. `build:android:dev` / `build:android:test` |
-
-Remove: “simulator is not sufficient for reliable silent push / **APNs**”.
-
-Add: emulator vs physical device guidance for FCM and background limits.
-
-### §4 — Generate and open the iOS workspace
-
-**Replace entirely** with Android equivalent:
-
-- `npm install`
-- `npm run build:android:dev` or `build:android:test` (non-production for debug panel)
-- `npx cap sync android` if needed
-- Open `android/` in Android Studio
-- Run on physical device (USB debugging)
-- `VITE_FIREBASE_*` in Capacitor web build
-- `initializeNativePushAndFirebaseMessaging()` in `main.capacitor.ts` — same entry point
-
-Do **not** reference `.xcworkspace`, signing in Xcode, or `build:ios:*` except as cross-link to iOS doc.
-
-### §5 — Firebase + APNs setup (first-time setup)
-
-**Keep (Android-relevant portions only):**
-
-- Firebase account / Spark plan sufficient for FCM
-- Create Firebase project
-- **Register Android app** in Firebase (package name `app.timesafari` from `capacitor.config.ts`)
-- Download **`google-services.json`** → `android/app/` (project may gitignore this file — document secure handling)
-- Firebase Admin service account for **notification-wakeup-service** — same as iOS §5 tail
-
-**Remove entirely:**
-
-- Register **iOS** app in Firebase (or move to “shared project” sidebar: one Firebase project, two apps)
-- **GoogleService-Info.plist** / Xcode drag-and-drop
-- **Create APNs Authentication Key** (.p8)
-- **Upload APNs key to Firebase**
-- **Enable iOS capabilities** (Push Notifications, Background Modes → Remote notifications)
-
-**Add in Android guide (see next major section):**
-
-- Gradle plugin / `google-services` classpath if not already in repo
-- `POST_NOTIFICATIONS` permission (API 33+)
-- Default notification channel / Capacitor Push Notifications Android setup
-- SHA-1/SHA-256 only if using Firebase features that require it (note whether wakeup testing needs Play App Signing keys)
-
-### §5 verify checklist — iOS-only bullets
-
-Replace:
-
-- “Xcode without Firebase/plist errors” → Android Studio build; `google-services.json` present
-- “iOS push permission prompt” → Android 13+ notification permission + older grant model
-- “content-available style payload” → Android **high-priority data message** / FCM options as implemented by **notification-wakeup-service** (document actual payload; no APNs `content-available`)
-
-### §7 — Firebase and Xcode checklist (iOS)
-
-**Replace** with Android checklist, e.g.:
-
-| Item | Action |
-|------|--------|
-| **Application ID** | `app.timesafari` in `capacitor.config.ts`, `android/app/build.gradle`, Firebase Android app |
-| **google-services.json** | In `android/app/`; not committed if gitignored — local copy per developer |
-| **Gradle** | Google services plugin applied (verify repo’s current `build.gradle`) |
-| **Permissions** | `POST_NOTIFICATIONS` (API 33+); manifest entries for FCM |
-| **FCM token** | Debug panel **Register Token Now** + ngrok `POST /notifications/register` |
-| **No APNs** | N/A on Android |
-
-### §8 — iOS-specific testing notes
-
-**Replace** with Android-specific sections (draft topics below). Do not port:
-
-- APNs silent delivery / Simulator unreliability (iOS framing)
-- **Force-quit** via app switcher (iOS-specific policy)
-- **Low Power Mode** (iOS) — Android has different battery saver APIs
-- **Focus / Do Not Disturb** (iOS naming)
-
-Port with Android wording:
-
-- Two **Simulate WAKEUP_PING** buttons table — unchanged behavior
-
-### §11 — Troubleshooting (partial)
-
-**Reuse as-is:**
-
-- Refresh endpoint unreachable (ngrok, URL, 404, CORS note)
-- Stale ngrok URL
-- Plugin / JWT errors after refresh
-
-**Rewrite:**
-
-| iOS troubleshooting | Android replacement |
-|----------------------|---------------------|
-| Push permission + `VITE_FIREBASE_*` + **Xcode** log | Permission (runtime POST_NOTIFICATIONS), logcat, Firebase Android config |
-| Silent push not waking — **backgrounded not force-quit**, **APNs key**, wait 30–120s | FCM high-priority data, **force-stop** (`STOP` from settings), **Doze**, battery optimization, OEM autostart, token mismatch |
-| Physical device + provisioning profile | USB debugging, correct build variant, Play vs debug signing if relevant |
-
-### §13 — Related docs
-
-Keep iOS-centric links as “see also”; add:
-
-- [android-physical-device-guide.md](./android-physical-device-guide.md)
-- `BUILDING.md` — Android build commands (`build:android:*`)
-- **daily-notification-plugin** Android docs (exact alarm, pending inspector on Android)
-
----
-
-## Android-Specific Topics Required
-
-These sections do not exist in the iOS guide (or exist only by analogy) and must be written for the Android notification testing doc.
-
-### Firebase project setup
-
-- Use the **same** Firebase project as iOS when testing the same backend, or document a dedicated `timesafari-dev` project.
-- Add an **Android** app with package name **`app.timesafari`**.
-- Enable **Cloud Messaging** (default on new projects).
-- Download **`google-services.json`** and install under `android/app/`.
-- Note: `android/.gitignore` may exclude `google-services.json` — developers copy locally; never commit secrets.
-
-### google-services.json
-
-- Placement: `android/app/google-services.json`
-- Sync after add: `npx cap sync android`, rebuild in Android Studio
-- Verify build merges Firebase config (no “missing google-services” Gradle errors)
-- Relationship to `VITE_FIREBASE_*` for the web layer / Capacitor JS Firebase initialization
-
-### Android notification permissions
-
-- **Android 13+ (API 33):** `POST_NOTIFICATIONS` runtime permission — required for notification **display**; document interaction with **data-only** FCM wake (may still deliver to app code when permission denied — verify against current app behavior and document accurately).
-- **Android 12 and below:** install-time grant model; fewer runtime prompts.
-- App Settings → Notifications — manual enable path for testers.
-- Link [notification-permissions-and-rollovers.md](./notification-permissions-and-rollovers.md) for product-level permission UX.
-
-### FCM token handling
-
-- Token obtained via Capacitor Push Notifications + `firebaseMessagingClient.ts` (same JS path as iOS).
-- **Register Token Now** in debug panel → `POST /notifications/register` with `platform: "android"`.
-- Token rotation: when to re-register; duplicate skip behavior in panel.
-- Ensure **notification-wakeup-service** stores/sends to the token shown in the panel for `/debug/send-wakeup`.
-- Optional: `adb` cannot easily read FCM token — panel is source of truth (same as iOS).
-
-### Android background delivery behavior
-
-- FCM **data** messages handled in foreground/background per Capacitor plugin and `NativeNotificationService.ts`.
-- No APNs intermediary — document expected latency vs iOS.
-- **High-priority** FCM for wakeup testing (align with backend message options).
-- App in **background** vs **foreground** vs **killed** — different from iOS “swipe away” story:
-  - **Force stop** (Settings → Force stop): delivery often blocked until user launches app again (stricter than iOS “backgrounded”).
-  - **Recent apps swipe**: behavior varies by OEM/Android version — document “test with Home button background, not force stop.”
-- `pushNotificationReceived` / listener registration at startup (`main.capacitor.ts`).
-
-### Doze Mode
-
-- Device idle → deferred network and job execution.
-- Testing: use `adb shell dumpsys deviceidle` (document safe dev-only commands) or unplugged idle wait.
-- Explain why `/debug/send-wakeup` may succeed on server but device wakes late.
-- Whitelisting app for tests (developer settings) — use cautiously; note production users won’t do this.
-
-### Battery optimization
-
-- Settings → Apps → TimeSafari → Battery → **Unrestricted** vs **Optimized**.
-- Manufacturer “battery saver” modes that restrict background network.
-- Recommend **Unrestricted** (or equivalent) for local wakeup validation; warn that production users may remain optimized.
-
-### OEM restrictions (Samsung, Xiaomi, Oppo, etc.)
-
-- **Autostart** / **Background activity** / **Battery** menus on Samsung, Xiaomi (MIUI), Oppo/ColorOS, Huawei, OnePlus, etc.
-- Symptom: FCM works on Pixel but not on OEM device until autostart enabled.
-- Provide a short “if wake fails on OEM, check…” checklist without exhaustive per-OEM screenshots (link community docs if needed).
-- Physical device testing should include at least one **stock-ish** device (Pixel) and one **OEM** device when possible.
-
----
-
-## Proposed outline for `doc/local-android-testing-ngrok.md`
-
-Suggested section order mirroring iOS doc for easy maintenance:
-
-1. Title, audience, goal (Android physical device + ngrok + wakeup service)
-2. Architecture overview (FCM direct to Android)
-3. Prerequisites (Android Studio, device, Firebase Android app, non-prod build)
-4. ngrok install, account, tunnel (**reuse iOS §1**)
-5. Start notification-wakeup-service (**reuse iOS §2**)
-6. ngrok HTTPS URL (**reuse iOS §3**)
-7. Build and open Android project (**new**, replaces iOS §4)
-8. Firebase setup for Android (**new**, replaces iOS §5 — no APNs)
-9. Notification Debug Panel (**reuse iOS §6**)
-10. Android configuration checklist (**new**, replaces iOS §7)
-11. Android-specific testing notes (**new**, replaces iOS §8)
-12. Recommended debug workflow (**reuse iOS §9** + logcat)
-13. Sample curl commands (**reuse iOS §10** + `platform: "android"`)
-14. Troubleshooting (**merge reusable + Android push rows**)
-15. Key source files (**reuse iOS §12**)
-16. Related docs (**iOS doc + Android device guide + BUILDING**)
-
----
-
-## Wording and terminology substitutions
-
-When adapting reused sections:
-
-| iOS doc term | Android doc term |
-|--------------|------------------|
-| iPhone | Android phone / device |
-| Xcode console | logcat / Android Studio Logcat |
-| `build:ios:dev` / `test` | `build:android:dev` / `test` |
-| `GoogleService-Info.plist` | `google-services.json` |
-| APNs / silent push | FCM data message / high-priority data |
-| Bundle ID | Application ID / package name (`app.timesafari`) |
-| Physical iPhone required for APNs | Physical device strongly recommended for Doze/OEM/FCM realism |
-| `platform: "ios"` in curl | `platform: "android"` |
-
----
-
-## Gaps to resolve while writing the Android guide
-
-Research during authoring (code + **notification-wakeup-service** + **daily-notification-plugin**):
-
-1. Exact FCM Android message priority and payload fields for `WAKEUP_PING` (parity with iOS data message).
-2. Whether `POST_NOTIFICATIONS` denial blocks data message delivery to JS listeners on API 33+.
-3. Gradle/Firebase plugin versions already in `android/` — document exact files to touch.
-4. Android **Pending Notification Inspector** parity with iOS panel section.
-5. Whether emulator with Google Play image is acceptable for minimal FCM smoke tests vs mandatory physical device for wakeup SLA testing.
-
----
-
-## Document maintenance
-
-| Document | Role |
-|----------|------|
-| [local-ios-testing-ngrok.md](./local-ios-testing-ngrok.md) | Canonical iOS + ngrok workflow (unchanged by this analysis) |
-| **This file** | Reuse vs rewrite matrix and Android topic backlog |
-| *Future* `local-android-testing-ngrok.md` | Operator guide for Android testers |
-
-When backend or debug panel behavior changes, update **both** platform guides’ shared sections in lockstep (or extract shared “ngrok + debug panel” snippet later — out of scope unless requested).

doc/local-ios-testing-ngrok.md

@@ -1,543 +0,0 @@
-# Local iOS Testing with ngrok (notification-wakeup-service)
-
-**Last updated:** 2026-05-18  
-**Audience:** Developers on **crowd-funder-for-time-pwa**, **daily-notification-plugin**, and **notification-wakeup-service**  
-**Goal:** Exercise silent push wake (`WAKEUP_PING`), FCM token registration, and notification refresh against a Mac-hosted backend reachable from a physical iPhone.
-
----
-
-## Architecture overview
-
-End-to-end flow when testing New Activity / silent wake on a physical iPhone:
-
-```text
-┌─────────────────────┐     HTTPS      ┌──────────────────────┐
-│  Mac (localhost)    │ ◄───────────── │  ngrok edge           │
-│  notification-      │   tunnel       │  (public HTTPS URL)   │
-│  wakeup-service     │                └──────────┬───────────┘
-└──────────┬──────────┘                           │
-           │                                        │ fetch
-           │ POST /notifications/refresh            │ POST /notifications/register
-           │                                        ▼
-           │                             ┌──────────────────────┐
-           │                             │  crowd-funder-for-     │
-           │                             │  time-pwa (Capacitor   │
-           │                             │  iOS on iPhone)        │
-           │                             └──────────┬───────────┘
-           │                                        │
-           │  FCM data message (WAKEUP_PING)        │ daily-notification-plugin
-           ▼                                        ▼ (local schedule replace)
-┌─────────────────────┐                ┌──────────────────────┐
-│  Firebase Cloud      │ ──APNs──────► │  iPhone (physical)   │
-│  Messaging           │  silent push  │  app.timesafari      │
-└─────────────────────┘                └──────────────────────┘
-```
-
-### Repos and responsibilities
-
-| Repo | Role |
-|------|------|
-| **notification-wakeup-service** | HTTP API: device registration, refresh payload (`nextNotifications`), health, debug wakeup send |
-| **crowd-funder-for-time-pwa** | Capacitor app: FCM token, `POST /notifications/register` & `/refresh`, handles `WAKEUP_PING` push |
-| **daily-notification-plugin** | Native iOS/Android: clear + reschedule local notifications from refresh timestamps |
-
-### Silent wake sequence (production path)
-
-1. Backend (or `/debug/send-wakeup`) sends an FCM **data** message with `data.type = "WAKEUP_PING"`.
-2. APNs delivers to the device (best-effort; see iOS caveats below).
-3. Capacitor `pushNotificationReceived` fires → `handleCapacitorPushNotificationReceived()`.
-4. App calls `POST {backend}/notifications/refresh` with `testMode` (from debug config).
-5. Backend returns `nextNotifications: [{ timestamp }, ...]`.
-6. App calls `applyNotificationRefreshPayload()` → plugin clears and schedules new local alarms.
-
-Console and debug panel lines are prefixed with **`[Notifications]`** (see `NotificationDebugEvents.ts`).
-
----
-
-## Prerequisites
-
-- Mac with Xcode, Node.js 18+, and the **notification-wakeup-service** repo cloned and runnable
-- Physical iPhone (USB or wireless debugging) — **simulator is not sufficient** for reliable silent push / APNs behavior
-- ngrok account (free tier is enough for dev)
-- Firebase project with APNs configured for the iOS app bundle ID
-- Non-production app build (Notification Debug Panel is dev-only)
-
----
-
-## 1. Install and configure ngrok (macOS)
-
-### Install
-
-```bash
-# Homebrew
-brew install ngrok/ngrok/ngrok
-```
-
-Or download from [https://ngrok.com/download](https://ngrok.com/download).
-
-### Account and auth token
-
-1. Sign up at [https://dashboard.ngrok.com/signup](https://dashboard.ngrok.com/signup).
-2. Copy your authtoken from **Your Authtoken** in the dashboard.
-3. Configure the CLI:
-
-```bash
-ngrok config add-authtoken YOUR_AUTHTOKEN_HERE
-```
-
-### Start a tunnel to the wakeup service
-
-Assume the service listens on port **3000** (confirm in **notification-wakeup-service** `README` or `.env`).
-
-If the service already defaults to port 3000 internally, you may not need to export PORT manually.
-
-```bash
-# Terminal A — backend
-cd /path/to/notification-wakeup-service
-
-npm install
-
-# one-time setup if needed
-cp .env.example .env
-
-# configure Firebase/service account/etc as required
-export PORT=3000
-
-npm run dev
-```
-
-```bash
-# Terminal B — ngrok
-ngrok http 3000
-```
-
-The backend only needs to be started once. The dedicated backend section below exists for verification and troubleshooting details, not as a second startup step.
-
-ngrok prints a forwarding URL, for example:
-
-```text
-Forwarding   https://abc123.ngrok-free.app -> http://localhost:3000
-```
-
-Use the **HTTPS** URL (not `http://127.0.0.1:3000`). The iPhone cannot reach your Mac’s localhost without the tunnel.
-
-> **Note:** Free ngrok URLs change every time you restart ngrok unless you use a reserved domain (paid). Update the app debug override whenever the URL changes.
-
----
-
-## 2. Start the backend locally
-
-Example (adjust to match **notification-wakeup-service**). On first setup, copy `.env.example` to `.env` and set Firebase service account, `PORT`, and other variables per that repo's docs.
-
-If the backend is not already running from section 1:
-
-```bash
-# If not already running from the previous step:
-cd /path/to/notification-wakeup-service
-npm run dev
-```
-
-Verify locally before ngrok:
-
-```bash
-curl -sS http://localhost:3000/health
-```
-
-Expected: HTTP 200 and a JSON body indicating the service is up (exact shape depends on that repo).
-
----
-
-## 3. Obtain and use the ngrok HTTPS URL
-
-1. Run `ngrok http <PORT>`.
-2. Copy the `https://….ngrok-free.app` host from the **Forwarding** line.
-3. Do **not** add a trailing slash when saving in the app (the debug config trims it).
-4. Optional: open `http://127.0.0.1:4040` (ngrok web UI) to inspect requests and responses while testing.
-
-Test through the tunnel from your Mac:
-
-```bash
-export NGROK_URL="https://abc123.ngrok-free.app"
-curl -sS "$NGROK_URL/health"
-```
-
----
-
-## 4. Generate and open the iOS workspace
-
-From **crowd-funder-for-time-pwa**, generate the Capacitor iOS project and open it in Xcode. **[Section 5](#5-firebase--apns-setup-first-time-setup) (Firebase + APNs)** needs this workspace—for example to add `GoogleService-Info.plist` and enable Push Notifications in the app target. The app does not need Firebase or push fully configured yet; the goal here is a buildable Xcode project on your Mac.
-
-```bash
-npm install
-npm run build:ios:dev    # or build:ios:test — non-production for debug panel
-```
-
-Open the generated Xcode workspace (for example `ios/App/App.xcworkspace`), select your **physical iPhone**, enable signing, and Run when you are ready to verify the app launches.
-
-Ensure `VITE_FIREBASE_*` variables are set for the Capacitor build you use (see `.env` / build docs). Native push registration runs at startup via `initializeNativePushAndFirebaseMessaging()` in `main.capacitor.ts` once Firebase is configured in the next section.
-
----
-
-## 5. Firebase + APNs setup (first-time setup)
-
-Complete this section once before your first physical-device push test. If Firebase and APNs are already configured for this app, skip to [section 6](#6-configure-the-notification-debug-panel-backend-override).
-
-### Create or access a Firebase account
-
-1. Sign in with a Google account at [https://console.firebase.google.com/](https://console.firebase.google.com/).
-
-2. If this is your first time using Firebase:
-   - Accept the Firebase terms.
-   - Create a new Firebase account/workspace when prompted.
-
-3. No paid Firebase plan is required for local iOS notification testing. The free **Spark** plan is sufficient for:
-   - Firebase Cloud Messaging (FCM)
-   - APNs silent push testing
-   - local ngrok-based development
-
-### Create a Firebase project
-
-1. In the [Firebase Console](https://console.firebase.google.com/), click **Add project** (or **Create a project**).
-2. Enter a project name (for example, `timesafari-dev`) and continue through the wizard.
-3. **Google Analytics** is optional for this workflow; you can disable it for a simpler dev project.
-4. When the project is created, open it. **Cloud Messaging** is available on all projects — you do not need a separate enable step for FCM.
-
-### Register the iOS app in Firebase
-
-1. In the project overview, click the **iOS** icon (**Add app** → iOS).
-2. Enter the **Apple bundle ID**. It must **exactly** match the Capacitor / Xcode app ID:
-   - **`app.timesafari`** (see `appId` in `capacitor.config.ts` and the Xcode target **Bundle Identifier**).
-3. App nickname and App Store ID are optional for local testing; continue.
-4. Download **`GoogleService-Info.plist`** when prompted and keep it handy for the next step.
-
-### Add GoogleService-Info.plist to Xcode
-
-1. Open the iOS workspace you generated in [section 4](#4-generate-and-open-the-ios-workspace) (for example `ios/App/App.xcworkspace`).
-2. In the Project Navigator, drag **`GoogleService-Info.plist`** into the **App** folder (the same one that contains AppDelegate.swift and Info.plist).
-3. In the dialog that appears:
-   - Check **Copy items if needed** (so the file is copied into the project tree).
-   - Under **Add to targets**, ensure the main app target (not only the share extension) is checked.
-4. Confirm the file appears under the app target in Xcode and is listed in **Build Phases** → **Copy Bundle Resources** if your project uses that phase for plists.
-
-### Create an APNs Authentication Key
-
-Apple uses APNs to deliver pushes to devices; Firebase needs an APNs key to talk to Apple on your behalf.
-
-1. Sign in to [Apple Developer](https://developer.apple.com/account/) → **Certificates, Identifiers & Profiles**.
-2. Open **Keys** → **+** (create a new key).
-3. Name the key (for example, `Timesafari APNs Dev`).
-4. Enable **Apple Push Notifications service (APNs)** and continue.
-5. Register the key, then **Download** the `.p8` file. **You can download it only once** — store it securely.
-6. Note:
-   - **Key ID** (shown on the key detail page)
-   - **Team ID** (top right of the developer portal, or **Membership** details)
-
-### Upload APNs key to Firebase
-
-1. Firebase Console → your project → **Project settings** (gear icon).
-2. Open the **Cloud Messaging** tab.
-3. Under **Apple app configuration**, select your iOS app (`app.timesafari`) if prompted.
-4. Under **APNs Authentication Key**, click **Upload**.
-5. Select the `.p8` file and enter:
-   - **Key ID**
-   - **Team ID**
-6. Save. Firebase can now send FCM messages through APNs to your iOS app.
-
-### Enable iOS capabilities in Xcode
-
-1. Select the **App** target → **Signing & Capabilities**.
-2. Click **+ Capability** and add **Push Notifications**.
-3. Click **+ Capability** again and add **Background Modes**.
-4. Under Background Modes, enable **Remote notifications**.
-
-These match what silent / data wake flows expect for background delivery.
-
-### Configure Firebase Admin for the backend
-
-**notification-wakeup-service** uses the Firebase Admin SDK to send FCM (and thus APNs) messages from your Mac.
-
-1. Firebase Console → **Project settings** → **Service accounts**.
-2. Click **Generate new private key** and confirm download of the JSON file.
-3. Store the JSON outside the repo (do not commit it).
-4. Point the backend at it, for example:
-
-```bash
-export GOOGLE_APPLICATION_CREDENTIALS="/absolute/path/to/service-account.json"
-```
-
-The backend uses this credential to authenticate with Firebase when calling endpoints such as `/debug/send-wakeup`. Set the same variable (or the equivalent env var documented in **notification-wakeup-service**) in the shell where you run `npm run dev`, or add it to that repo’s `.env` per its README.
-
-### Verify Firebase configuration
-
-Before ngrok end-to-end testing, confirm:
-
-- [ ] App builds and launches on a **physical** iPhone without Firebase/plist errors in Xcode.
-- [ ] iOS shows the push **permission** prompt (or Settings → app → Notifications is enabled).
-- [ ] **Notification Debug Panel** shows an FCM token (after permission).
-- [ ] **Register Token Now** succeeds and ngrok (or local backend) shows `POST /notifications/register`.
-- [ ] Backend health and Firebase Admin env are set so `/debug/send-wakeup` can run when you reach that step in the workflow below.
-
----
-
-## 6. Configure the Notification Debug Panel backend override
-
-The app normally calls `DEFAULT_NOTIFY_API_SERVER` (from `VITE_DEFAULT_NOTIFY_API_SERVER`, falling back to `AppString.PROD_NOTIFY_API_SERVER`). That is independent of `APP_SERVER`. For local wakeup testing, override the notification API base URL in the Debug Panel without rebuilding.
-
-For a full panel reference (configuration, URL resolution order, authentication, and troubleshooting), see [notification-debug-panel.md](./notification-debug-panel.md).
-
-### Open the panel
-
-1. Use a **non-production** bundle (e.g. dev/test build).
-2. **Account** → enable **Show All General Advanced Functions**.
-3. Open **Notification Debug Panel** (route `/dev/notifications`).
-
-### Backend Testing section
-
-| Control | Purpose |
-|---------|---------|
-| **Notification Backend URL** | Paste ngrok HTTPS URL → **Save Backend URL** (changes target server only) |
-| **Test Mode** | Sends `testMode: true/false` in register/refresh JSON bodies (default on when unset in storage) |
-| **Skip JWT Authentication (Local Development Only)** | When on, omits `Authorization` headers for local servers that accept unauthenticated requests (default **off**) |
-| **Register Token Now** | `POST /notifications/register` with current FCM token |
-| **Refresh Notifications** | `POST /notifications/refresh` (same as post-wakeup flow) |
-| **Simulate WAKEUP_PING (Local)** | Calls refresh API directly (no FCM) — quick backend test |
-| **Send Real WAKEUP_PING** | `POST /debug/send-wakeup`; server sends real FCM `WAKEUP_PING` (Android doc has full flow) |
-| **Event Log** | Shared `[Notifications]` panel log (100 entries) |
-
-Persistence: `localStorage` keys `notificationDebug.backendBaseUrl`, `notificationDebug.testMode`, and `notificationDebug.bypassAuth` (`NotificationDebugConfig.ts`).
-
-### Authentication vs backend URL
-
-These settings are **independent**:
-
-- **Backend URL** — which server receives notification API calls.
-- **Test Mode** — `testMode` field in JSON request bodies only.
-- **Skip JWT Authentication** — whether JWT `Authorization` headers are sent.
-
-For a **hosted shared test server**: set the backend URL, keep **Test Mode** on if required, leave **Skip JWT Authentication** **off**, and ensure an active DID exists.
-
-For **local ngrok**: set the backend URL; enable **Skip JWT Authentication** only if your local backend accepts unauthenticated requests.
-
-### Programmatic override (optional)
-
-From Safari Web Inspector or a dev console attached to the WebView:
-
-```javascript
-import {
-  setBackendBaseUrl,
-  setTestMode,
-  setBypassAuth,
-  getNotificationApiBaseUrl,
-} from "@/services/notifications";
-
-setBackendBaseUrl("https://abc123.ngrok-free.app");
-setTestMode(true);
-setBypassAuth(true); // local dev only — omit for hosted servers that require JWT
-getNotificationApiBaseUrl(); // → ngrok URL
-```
-
----
-
-## 7. Firebase and Xcode checklist (iOS)
-
-This section is a quick verification checklist for the detailed Firebase/APNs setup steps above.
-
-| Item | Action |
-|------|--------|
-| **Bundle ID** | Match Capacitor `appId` (`app.timesafari` in `capacitor.config.ts`) to Firebase iOS app and Xcode target |
-| **APNs auth key** | Firebase Console → Project Settings → Cloud Messaging → upload **APNs Authentication Key** (.p8) or certificates |
-| **Push Notifications** | Xcode target → **Signing & Capabilities** → **+ Capability** → **Push Notifications** |
-| **Background Modes** | Enable **Remote notifications** (and any others required by your plugin docs) |
-| **GoogleService-Info.plist** | Present in the iOS target if using Firebase iOS SDK paths in your build |
-| **FCM token** | Confirm **Register Token Now** succeeds in the debug panel and ngrok shows `POST /notifications/register` |
-
-Silent/data pushes used for wake typically use a **content-available** style payload; confirm **notification-wakeup-service** and Firebase message format match what `handleCapacitorPushNotificationReceived` expects (`data.type === "WAKEUP_PING"`).
-
----
-
-## 8. iOS-specific testing notes
-
-### Physical device required
-
-- APNs silent delivery and background wake behavior are **not** representative on the iOS Simulator.
-- Always validate on a plugged-in or trusted wireless device with a development provisioning profile.
-
-### Silent push is best-effort
-
-- iOS may **delay or coalesce** background pushes, especially on battery saver or under load.
-- A successful `/debug/send-wakeup` from the server does not guarantee immediate app wake.
-
-### Force-quit limitations
-
-- If the user **swipes the app away** from the app switcher, iOS often **will not** deliver background notifications until the user launches the app again.
-- Test with the app **backgrounded** (home button / gesture), not force-quit, when validating wake.
-
-### Low Power Mode and Focus
-
-- **Low Power Mode** can reduce background execution.
-- **Focus / Do Not Disturb** may affect notification presentation (separate from silent data wake, but confusing during tests).
-
-### Two “Simulate WAKEUP_PING” buttons
-
-| Button | Behavior |
-|--------|----------|
-| **Backend Testing → Simulate WAKEUP_PING** | Skips FCM; calls refresh API only (ngrok path test) |
-| **Wakeup Ping Simulator** (lower on panel) | Runs production handler with synthetic `WAKEUP_PING` payload |
-
-Use the backend button to verify ngrok + refresh; use the simulator to verify handler + refresh chaining.
-
----
-
-## 9. Recommended debug workflow
-
-1. Start **notification-wakeup-service** on the Mac.
-2. Start **ngrok** and copy the HTTPS URL.
-3. Set URL + **Test Mode** in the Notification Debug Panel; confirm **Backend Status**.
-4. Tap **Register Token Now** → confirm ngrok request and `[Notifications] Token registration success`.
-5. Tap **Refresh Notifications** → confirm `Refresh completed in Nms (scheduled X)` in Event Log and ngrok `POST /notifications/refresh`.
-6. From the backend, call **`/debug/send-wakeup`** (see curl below) with the registered `deviceId` / FCM token as required by that service.
-7. Watch **Xcode console** for `[Notifications] pushNotificationReceived type=WAKEUP_PING` and refresh timing lines.
-8. Open **ngrok inspect UI** (`http://127.0.0.1:4040`) to correlate requests.
-9. Use **Pending Notification Inspector** on the panel to see locally scheduled fires after refresh.
-
----
-
-## 10. Sample curl commands
-
-Set your tunnel base URL:
-
-```bash
-export BASE="https://abc123.ngrok-free.app"
-```
-
-### Health
-
-```bash
-curl -sS -w "\nHTTP %{http_code}\n" "$BASE/health"
-```
-
-### Register device (mirror app payload)
-
-```bash
-curl -sS -X POST "$BASE/notifications/register" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "deviceId": "00000000-0000-4000-8000-000000000001",
-    "fcmToken": "YOUR_FCM_TOKEN_FROM_DEBUG_PANEL",
-    "platform": "ios",
-    "testMode": true
-  }'
-```
-
-### Refresh (mirror app payload)
-
-```bash
-curl -sS -X POST "$BASE/notifications/refresh" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "platform": "ios",
-    "testMode": true
-  }'
-```
-
-Example success body shape (actual fields may vary by service version):
-
-```json
-{
-  "shouldNotify": true,
-  "nextNotifications": [
-    { "timestamp": 1710000000000 },
-    { "timestamp": 1710003600000 }
-  ]
-}
-```
-
-The app schedules those timestamps via **daily-notification-plugin** (`applyNotificationRefreshPayload` in `NativeNotificationService.ts`).
-
-### Send wakeup push (debug)
-
-Exact path and body depend on **notification-wakeup-service**; typical pattern:
-
-```bash
-curl -sS -X POST "$BASE/debug/send-wakeup" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "deviceId": "00000000-0000-4000-8000-000000000001",
-    "testMode": true
-  }'
-```
-
-Confirm parameters (token vs deviceId, auth headers) in that repo’s README or OpenAPI spec.
-
----
-
-## 11. Troubleshooting
-
-### Refresh endpoint unreachable
-
-| Symptom | Checks |
-|---------|--------|
-| Network error in Event Log | ngrok running? URL saved without typo/trailing slash? |
-| HTTP 404 | Tunnel port matches backend `PORT`; path is `/notifications/refresh` |
-| CORS (web only) | Native Capacitor fetch usually avoids browser CORS; if testing in Safari PWA, configure CORS on the service |
-| ngrok browser warning | Free tier may show an interstitial for browser clients; native `fetch` from the app is usually unaffected |
-
-### Token registration failures
-
-- Push permission granted on the device?
-- Firebase `VITE_FIREBASE_*` env vars baked into the build?
-- `[Notifications] Token registration failure` in Xcode — read HTTP status in ngrok inspect
-- Duplicate token skip: panel may show “skipped (duplicate)”; use **Register Token Now** to force re-register
-
-### Silent push not waking the app
-
-- App **backgrounded**, not force-quit
-- Physical device, correct provisioning profile
-- APNs key uploaded to Firebase; bundle ID matches
-- FCM message includes `data.type = "WAKEUP_PING"` (see `NativeNotificationService.ts`)
-- Server actually sent to the **same** FCM token shown in the debug panel
-- Wait 30–120s — delivery is not instant
-- Try **Simulate WAKEUP_PING** (refresh API) to isolate app/plugin from FCM/APNs
-
-### Notifications duplicating
-
-- Multiple refresh calls (flood test, repeated wakeups) each **replace** schedule via clear + schedule — check Event Log for repeated refreshes
-- Separate issue: Daily Reminder vs New Activity both scheduling — see `doc/notification-new-activity-lay-of-the-land.md`
-
-### Stale ngrok URL
-
-- After restarting ngrok, update **Notification Backend URL** in the panel and tap **Save**
-- Or clear override (empty field + Save) only if you intend to hit `DEFAULT_NOTIFY_API_SERVER` again
-
-### Plugin / JWT errors after refresh
-
-- Refresh calls `configureNativeFetcherIfReady()` before scheduling — ensure an **active DID** and endorser API settings exist in the app DB
-- See `doc/notification-from-api-call.md` and `nativeFetcherConfig.ts`
-
----
-
-## 12. Key source files (crowd-funder-for-time-pwa)
-
-| File | Purpose |
-|------|---------|
-| `src/services/notifications/NotificationDebugConfig.ts` | Backend URL, testMode, and bypassAuth overrides |
-| `src/services/notifications/NotificationDebugEvents.ts` | Panel event log + `logNotification()` |
-| `src/services/notifications/notificationLog.ts` | Structured log helpers |
-| `src/services/notifications/NotificationService.ts` | `POST /notifications/register` |
-| `src/services/notifications/NativeNotificationService.ts` | Refresh, `WAKEUP_PING`, schedule replace |
-| `src/services/notifications/firebaseMessagingClient.ts` | Capacitor push listeners |
-| `src/components/dev/NotificationDebugPanel.vue` | Dev UI |
-| `src/main.capacitor.ts` | Native push init at startup |
-
----
-
-## 13. Related docs
-
-- [notification-debug-panel.md](./notification-debug-panel.md) — panel controls, authentication, troubleshooting
-- [Notification Debug Panel (README)](../README.md#notification-debug-panel-dev-builds)
-- [notification-system-overview.md](./notification-system-overview.md)
-- [notification-from-api-call.md](./notification-from-api-call.md)
-- [notification-new-activity-lay-of-the-land.md](./notification-new-activity-lay-of-the-land.md)
-- [BUILDING.md](../BUILDING.md) — iOS build commands
-
-For plugin-native behavior (exact alarm, iOS pending inspector), see **daily-notification-plugin** documentation. For FCM payload format and `/debug/send-wakeup` contract, see **notification-wakeup-service**.

doc/meta_rule_usage_guide.md

@@ -32,6 +32,7 @@ you apply 1-3 meta-rules that automatically include everything you need.
 ### **Step 1: Always Start with Core Always-On**
 
 **Every single interaction** starts with:
+
 ```
 meta_core_always_on.mdc
 ```
@@ -65,12 +66,14 @@ meta_core_always_on + meta_research + meta_bug_diagnosis
 **Important**: Meta-rules represent **workflow phases**, not a rigid sequence. You can:
 
 ### **Jump Between Phases Freely**
+
 - **Start with diagnosis** if you already know the problem
 - **Go back to research** if your fix reveals new issues  
 - **Switch to planning** mid-implementation if scope changes
 - **Document at any phase** - not just at the end
 
 ### **Mode Switching by Invoking Meta-Rules**
+
 Each meta-rule invocation **automatically switches your workflow mode**:
 
 ```
@@ -80,11 +83,13 @@ Planning Mode → Invoke @meta_feature_implementation → Implementation Mode
 ```
 
 ### **Phase Constraints, Not Sequence Constraints**
+
 - **Within each phase**: Clear constraints on what you can/cannot do
 - **Between phases**: Complete freedom to move as needed
 - **No forced order**: Choose the phase that matches your current need
 
 ### **Example of Flexible Workflow**
+
 ```
 1. Start with @meta_research (investigation mode)
 2. Jump to @meta_bug_diagnosis (diagnosis mode) 
@@ -103,16 +108,19 @@ Planning Mode → Invoke @meta_feature_implementation → Implementation Mode
 **Scenario**: User reports that the contact list isn't loading properly
 
 **Initial Meta-Rule Selection**:
+
 ```
 meta_core_always_on + meta_research + meta_bug_diagnosis
 ```
 
 **What This Gives You**:
+
 - **Core Always-On**: Human competence focus, time standards, context
 - **Research**: Systematic investigation methodology, evidence collection
 - **Bug Diagnosis**: Defect analysis framework, root cause identification
 
 **Flexible Workflow**:
+
 1. Apply core always-on for foundation
 2. Use research meta-rule for systematic investigation
 3. Switch to bug diagnosis when you have enough evidence
@@ -125,16 +133,19 @@ meta_core_always_on + meta_research + meta_bug_diagnosis
 **Scenario**: Building a new contact search feature
 
 **Meta-Rule Selection**:
+
 ```
 meta_core_always_on + meta_feature_planning + meta_feature_implementation
 ```
 
 **What This Gives You**:
+
 - **Core Always-On**: Foundation principles and context
 - **Feature Planning**: Requirements analysis, architecture planning
 - **Feature Implementation**: Development workflow, testing strategy
 
 **Iterative Workflow**:
+
 1. Start with core always-on
 2. Use feature planning for design and requirements
 3. Switch to feature implementation for coding and testing
@@ -147,15 +158,18 @@ meta_core_always_on + meta_feature_planning + meta_feature_implementation
 **Scenario**: Writing a migration guide for the new database system
 
 **Meta-Rule Selection**:
+
 ```
 meta_core_always_on + meta_documentation
 ```
 
 **What This Gives You**:
+
 - **Core Always-On**: Foundation and context
 - **Documentation**: Educational focus, templates, quality standards
 
 **Parallel Workflow**:
+
 1. Apply core always-on for foundation
 2. Use documentation meta-rule for educational content creation
 3. **Can research** while documenting if you need more information
@@ -198,27 +212,35 @@ Each meta-rule includes success criteria. Use these to validate your work:
 ## Common Meta-Rule Combinations
 
 ### **Research + Diagnosis**
+
 ```
 meta_core_always_on + meta_research + meta_bug_diagnosis
 ```
+
 **Use for**: Complex bug investigations requiring systematic analysis
 
 ### **Planning + Implementation**
+
 ```
 meta_core_always_on + meta_feature_planning + meta_feature_implementation
 ```
+
 **Use for**: End-to-end feature development from concept to deployment
 
 ### **Research + Planning**
+
 ```
 meta_core_always_on + meta_research + meta_feature_planning
 ```
+
 **Use for**: Feasibility research and solution design
 
 ### **Documentation + Context**
+
 ```
 meta_core_always_on + meta_documentation + [context-specific]
 ```
+
 **Use for**: Creating comprehensive, educational documentation
 
 ## Best Practices

doc/native-share-target-implementation.md

@@ -1,507 +0,0 @@
-# Native Share Target Implementation Guide
-
-**Date:** 2025-01-27  
-**Purpose:** Enable TimeSafari native iOS and Android apps to receive shared images from other apps
-
-## Current State
-
-The app currently supports **PWA/web share target** functionality:
-- Service worker intercepts POST to `/share-target`
-- Images stored in temp database as base64
-- `SharedPhotoView.vue` processes and displays shared images
-
-**This does NOT work for native iOS/Android builds** because:
-- Service workers don't run in native app contexts
-- Native platforms use different sharing mechanisms (Share Extensions on iOS, Intent Filters on Android)
-
-## Required Changes
-
-### 1. iOS Implementation
-
-#### 1.1 Create Share Extension Target
-
-1. Open `ios/App/App.xcodeproj` in Xcode
-2. File → New → Target
-3. Select "Share Extension" template
-4. Name it "TimeSafariShareExtension"
-5. Bundle Identifier: `app.timesafari.shareextension`
-6. Language: Swift
-
-#### 1.2 Configure Share Extension Info.plist
-
-Add to `ios/App/TimeSafariShareExtension/Info.plist`:
-
-```xml
-<key>NSExtension</key>
-<dict>
-    <key>NSExtensionPointIdentifier</key>
-    <string>com.apple.share-services</string>
-    <key>NSExtensionPrincipalClass</key>
-    <string>$(PRODUCT_MODULE_NAME).ShareViewController</string>
-    <key>NSExtensionActivationRule</key>
-    <dict>
-        <key>NSExtensionActivationSupportsImageWithMaxCount</key>
-        <integer>1</integer>
-        <key>NSExtensionActivationSupportsFileWithMaxCount</key>
-        <integer>1</integer>
-    </dict>
-</dict>
-```
-
-#### 1.3 Implement ShareViewController
-
-Create `ios/App/TimeSafariShareExtension/ShareViewController.swift`:
-
-```swift
-import UIKit
-import Social
-import MobileCoreServices
-import Capacitor
-
-class ShareViewController: SLComposeServiceViewController {
-    
-    override func viewDidLoad() {
-        super.viewDidLoad()
-        self.title = "Share to TimeSafari"
-    }
-    
-    override func isContentValid() -> Bool {
-        return true
-    }
-    
-    override func didSelectPost() {
-        guard let extensionItem = extensionContext?.inputItems.first as? NSExtensionItem,
-              let itemProvider = extensionItem.attachments?.first else {
-            self.extensionContext?.completeRequest(returningItems: nil, completionHandler: nil)
-            return
-        }
-        
-        // Handle image sharing
-        if itemProvider.hasItemConformingToTypeIdentifier(kUTTypeImage as String) {
-            itemProvider.loadItem(forTypeIdentifier: kUTTypeImage as String, options: nil) { [weak self] (item, error) in
-                guard let self = self else { return }
-                
-                if let url = item as? URL {
-                    // Handle file URL
-                    self.handleSharedImage(url: url)
-                } else if let image = item as? UIImage {
-                    // Handle UIImage directly
-                    self.handleSharedImage(image: image)
-                } else if let data = item as? Data {
-                    // Handle image data
-                    self.handleSharedImage(data: data)
-                }
-            }
-        }
-    }
-    
-    private func handleSharedImage(url: URL? = nil, image: UIImage? = nil, data: Data? = nil) {
-        var imageData: Data?
-        var fileName: String?
-        
-        if let url = url {
-            imageData = try? Data(contentsOf: url)
-            fileName = url.lastPathComponent
-        } else if let image = image {
-            imageData = image.jpegData(compressionQuality: 0.8)
-            fileName = "shared-image.jpg"
-        } else if let data = data {
-            imageData = data
-            fileName = "shared-image.jpg"
-        }
-        
-        guard let imageData = imageData else {
-            self.extensionContext?.completeRequest(returningItems: nil, completionHandler: nil)
-            return
-        }
-        
-        // Convert to base64
-        let base64String = imageData.base64EncodedString()
-        
-        // Store in shared UserDefaults (accessible by main app)
-        let userDefaults = UserDefaults(suiteName: "group.app.timesafari.share")
-        userDefaults?.set(base64String, forKey: "sharedPhotoBase64")
-        userDefaults?.set(fileName ?? "shared-image.jpg", forKey: "sharedPhotoFileName")
-        userDefaults?.synchronize()
-        
-        // Open main app with deep link
-        let url = URL(string: "timesafari://shared-photo?fileName=\(fileName?.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) ?? "shared-image.jpg")")!
-        var responder = self as UIResponder?
-        while responder != nil {
-            if let application = responder as? UIApplication {
-                application.open(url, options: [:], completionHandler: nil)
-                break
-            }
-            responder = responder?.next
-        }
-        
-        // Close share extension
-        self.extensionContext?.completeRequest(returningItems: nil, completionHandler: nil)
-    }
-    
-    override func configurationItems() -> [Any]! {
-        return []
-    }
-}
-```
-
-#### 1.4 Configure App Groups
-
-1. In Xcode, select main app target → Signing & Capabilities
-2. Add "App Groups" capability
-3. Create group: `group.app.timesafari.share`
-4. Repeat for Share Extension target with same group name
-
-#### 1.5 Update Main App to Read from App Group
-
-The main app needs to check for shared images on launch. This should be added to `AppDelegate.swift` or handled in JavaScript.
-
-### 2. Android Implementation
-
-#### 2.1 Update AndroidManifest.xml
-
-Add intent filter to `MainActivity` in `android/app/src/main/AndroidManifest.xml`:
-
-```xml
-<activity
-    android:name=".MainActivity"
-    ... existing attributes ...>
-    
-    ... existing intent filters ...
-    
-    <!-- Share Target Intent Filter -->
-    <intent-filter>
-        <action android:name="android.intent.action.SEND" />
-        <category android:name="android.intent.category.DEFAULT" />
-        <data android:mimeType="image/*" />
-    </intent-filter>
-    
-    <!-- Multiple images support (optional) -->
-    <intent-filter>
-        <action android:name="android.intent.action.SEND_MULTIPLE" />
-        <category android:name="android.intent.category.DEFAULT" />
-        <data android:mimeType="image/*" />
-    </intent-filter>
-</activity>
-```
-
-#### 2.2 Handle Intent in MainActivity
-
-Update `android/app/src/main/java/app/timesafari/MainActivity.java`:
-
-```java
-package app.timesafari;
-
-import android.content.Intent;
-import android.net.Uri;
-import android.os.Bundle;
-import android.util.Base64;
-import android.util.Log;
-import com.getcapacitor.BridgeActivity;
-import com.getcapacitor.Plugin;
-import java.io.InputStream;
-import java.io.ByteArrayOutputStream;
-
-public class MainActivity extends BridgeActivity {
-    private static final String TAG = "MainActivity";
-    
-    @Override
-    protected void onCreate(Bundle savedInstanceState) {
-        super.onCreate(savedInstanceState);
-        handleShareIntent(getIntent());
-    }
-    
-    @Override
-    protected void onNewIntent(Intent intent) {
-        super.onNewIntent(intent);
-        setIntent(intent);
-        handleShareIntent(intent);
-    }
-    
-    private void handleShareIntent(Intent intent) {
-        if (intent == null) return;
-        
-        String action = intent.getAction();
-        String type = intent.getType();
-        
-        if (Intent.ACTION_SEND.equals(action) && type != null && type.startsWith("image/")) {
-            Uri imageUri = intent.getParcelableExtra(Intent.EXTRA_STREAM);
-            if (imageUri != null) {
-                handleSharedImage(imageUri, intent.getStringExtra(Intent.EXTRA_TEXT));
-            }
-        } else if (Intent.ACTION_SEND_MULTIPLE.equals(action) && type != null && type.startsWith("image/")) {
-            // Handle multiple images (optional - for now just take first)
-            java.util.ArrayList<Uri> imageUris = intent.getParcelableArrayListExtra(Intent.EXTRA_STREAM);
-            if (imageUris != null && !imageUris.isEmpty()) {
-                handleSharedImage(imageUris.get(0), null);
-            }
-        }
-    }
-    
-    private void handleSharedImage(Uri imageUri, String fileName) {
-        try {
-            // Read image data
-            InputStream inputStream = getContentResolver().openInputStream(imageUri);
-            if (inputStream == null) {
-                Log.e(TAG, "Failed to open input stream for shared image");
-                return;
-            }
-            
-            ByteArrayOutputStream buffer = new ByteArrayOutputStream();
-            byte[] data = new byte[8192];
-            int nRead;
-            while ((nRead = inputStream.read(data, 0, data.length)) != -1) {
-                buffer.write(data, 0, nRead);
-            }
-            buffer.flush();
-            byte[] imageBytes = buffer.toByteArray();
-            
-            // Convert to base64
-            String base64String = Base64.encodeToString(imageBytes, Base64.NO_WRAP);
-            
-            // Extract filename from URI or use default
-            String actualFileName = fileName;
-            if (actualFileName == null || actualFileName.isEmpty()) {
-                String path = imageUri.getPath();
-                if (path != null) {
-                    int lastSlash = path.lastIndexOf('/');
-                    if (lastSlash >= 0 && lastSlash < path.length() - 1) {
-                        actualFileName = path.substring(lastSlash + 1);
-                    }
-                }
-                if (actualFileName == null || actualFileName.isEmpty()) {
-                    actualFileName = "shared-image.jpg";
-                }
-            }
-            
-            // Store in SharedPreferences (accessible by JavaScript via Capacitor)
-            android.content.SharedPreferences prefs = getSharedPreferences("TimeSafariShared", MODE_PRIVATE);
-            android.content.SharedPreferences.Editor editor = prefs.edit();
-            editor.putString("sharedPhotoBase64", base64String);
-            editor.putString("sharedPhotoFileName", actualFileName);
-            editor.apply();
-            
-            // Trigger JavaScript event or navigate to shared-photo route
-            // This will be handled by JavaScript checking for shared data on app launch
-            Log.d(TAG, "Shared image stored, filename: " + actualFileName);
-            
-        } catch (Exception e) {
-            Log.e(TAG, "Error handling shared image", e);
-        }
-    }
-}
-```
-
-#### 2.3 Add Required Permissions
-
-Ensure `AndroidManifest.xml` has:
-
-```xml
-<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
-<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <!-- Android 13+ -->
-```
-
-### 3. JavaScript Layer Updates
-
-#### 3.1 Create Native Share Handler
-
-Create `src/services/nativeShareHandler.ts`:
-
-```typescript
-/**
- * Native Share Handler
- * Handles shared images from native iOS and Android platforms
- */
-
-import { Capacitor } from "@capacitor/core";
-import { App } from "@capacitor/app";
-import { Filesystem, Directory, Encoding } from "@capacitor/filesystem";
-import { logger } from "../utils/logger";
-import { SHARED_PHOTO_BASE64_KEY } from "../libs/util";
-import { PlatformServiceMixin } from "@/utils/PlatformServiceMixin";
-
-/**
- * Check for shared images from native platforms and store in temp database
- */
-export async function checkForNativeSharedImage(
-  platformService: InstanceType<typeof PlatformServiceMixin>
-): Promise<boolean> {
-  if (!Capacitor.isNativePlatform()) {
-    return false;
-  }
-
-  try {
-    if (Capacitor.getPlatform() === "ios") {
-      return await checkIOSSharedImage(platformService);
-    } else if (Capacitor.getPlatform() === "android") {
-      return await checkAndroidSharedImage(platformService);
-    }
-  } catch (error) {
-    logger.error("Error checking for native shared image:", error);
-  }
-
-  return false;
-}
-
-/**
- * Check for shared image on iOS (from App Group UserDefaults)
- */
-async function checkIOSSharedImage(
-  platformService: InstanceType<typeof PlatformServiceMixin>
-): Promise<boolean> {
-  // iOS uses App Groups to share data between extension and main app
-  // We need to use a Capacitor plugin or native code to read from App Group
-  // For now, this is a placeholder - requires native plugin implementation
-  
-  // Option 1: Use Capacitor plugin to read from App Group
-  // Option 2: Use native code bridge
-  
-  logger.debug("Checking for iOS shared image (not yet implemented)");
-  return false;
-}
-
-/**
- * Check for shared image on Android (from SharedPreferences)
- */
-async function checkAndroidSharedImage(
-  platformService: InstanceType<typeof PlatformServiceMixin>
-): Promise<boolean> {
-  // Android stores in SharedPreferences
-  // We need a Capacitor plugin to read from SharedPreferences
-  // For now, this is a placeholder - requires native plugin implementation
-  
-  logger.debug("Checking for Android shared image (not yet implemented)");
-  return false;
-}
-
-/**
- * Store shared image in temp database
- */
-async function storeSharedImage(
-  base64Data: string,
-  fileName: string,
-  platformService: InstanceType<typeof PlatformServiceMixin>
-): Promise<void> {
-  try {
-    const existing = await platformService.$getTemp(SHARED_PHOTO_BASE64_KEY);
-    
-    if (existing) {
-      await platformService.$updateEntity(
-        "temp",
-        { blobB64: base64Data },
-        "id = ?",
-        [SHARED_PHOTO_BASE64_KEY]
-      );
-    } else {
-      await platformService.$insertEntity(
-        "temp",
-        { id: SHARED_PHOTO_BASE64_KEY, blobB64: base64Data },
-        ["id", "blobB64"]
-      );
-    }
-    
-    logger.debug("Stored shared image in temp database");
-  } catch (error) {
-    logger.error("Error storing shared image:", error);
-    throw error;
-  }
-}
-```
-
-#### 3.2 Update main.capacitor.ts
-
-Add check for shared images on app launch:
-
-```typescript
-// In main.capacitor.ts, after app mount:
-
-import { checkForNativeSharedImage } from "./services/nativeShareHandler";
-
-// Check for shared images when app becomes active
-App.addListener("appStateChange", async (state) => {
-  if (state.isActive) {
-    // Check for native shared images
-    const hasSharedImage = await checkForNativeSharedImage(/* platformService */);
-    if (hasSharedImage) {
-      // Navigate to shared-photo view
-      await router.push({
-        name: "shared-photo",
-        query: { source: "native" }
-      });
-    }
-  }
-});
-
-// Also check on initial launch
-App.getLaunchUrl().then((result) => {
-  if (result?.url) {
-    // Handle deep link
-  } else {
-    // Check for shared image
-    checkForNativeSharedImage(/* platformService */).then((hasShared) => {
-      if (hasShared) {
-        router.push({ name: "shared-photo", query: { source: "native" } });
-      }
-    });
-  }
-});
-```
-
-#### 3.3 Update SharedPhotoView.vue
-
-The existing `SharedPhotoView.vue` should work as-is, but we may want to add detection for native vs web sources.
-
-### 4. Alternative Approach: Capacitor Plugin
-
-Instead of implementing native code directly, consider creating a Capacitor plugin:
-
-1. **Create plugin**: `@capacitor-community/share-target` or custom plugin
-2. **Plugin methods**:
-   - `checkForSharedImage()`: Returns shared image data if available
-   - `clearSharedImage()`: Clears shared image data after processing
-
-This would be cleaner and more maintainable.
-
-### 5. Testing Checklist
-
-- [ ] Test sharing image from Photos app on iOS
-- [ ] Test sharing image from Gallery app on Android
-- [ ] Test sharing from other apps (Safari, Chrome, etc.)
-- [ ] Verify image appears in SharedPhotoView
-- [ ] Test "Record Gift" flow with shared image
-- [ ] Test "Save as Profile" flow with shared image
-- [ ] Test cancel flow
-- [ ] Verify temp storage cleanup
-- [ ] Test app launch with shared image pending
-- [ ] Test app already running when image is shared
-
-### 6. Implementation Priority
-
-**Phase 1: Android (Simpler)**
-1. Update AndroidManifest.xml
-2. Implement MainActivity intent handling
-3. Create JavaScript handler
-4. Test end-to-end
-
-**Phase 2: iOS (More Complex)**
-1. Create Share Extension target
-2. Implement ShareViewController
-3. Configure App Groups
-4. Create JavaScript handler
-5. Test end-to-end
-
-### 7. Notes
-
-- **App Groups (iOS)**: Required for sharing data between Share Extension and main app
-- **SharedPreferences (Android)**: Standard way to share data between app components
-- **Base64 Encoding**: Both platforms convert images to base64 for JavaScript compatibility
-- **File Size Limits**: Consider large image handling and memory management
-- **Permissions**: Android 13+ requires `READ_MEDIA_IMAGES` instead of `READ_EXTERNAL_STORAGE`
-
-### 8. References
-
-- [iOS Share Extensions](https://developer.apple.com/documentation/social)
-- [Android Share Targets](https://developer.android.com/training/sharing/receive)
-- [Capacitor App Plugin](https://capacitorjs.com/docs/apis/app)
-- [Capacitor Native Bridge](https://capacitorjs.com/docs/guides/building-plugins)
-

doc/new-activity-notifications-ios-android-parity.md

@@ -1,158 +0,0 @@
-# New Activity Notifications: iOS Parity with Android
-
-**Purpose:** Describe what is required for **iOS** to match **Android** for the daily-notification-plugin **API-driven “New Activity”** flow (`scheduleDualNotification` / `cancelDualSchedule`, with prefetch and Endorser-backed content). The canonical product behavior is documented in `doc/notification-from-api-call.md` and `doc/notification-new-activity-lay-of-the-land.md`.
-
-**Plugin source of truth:** The Capacitor package is `@timesafari/daily-notification-plugin`, pulled from the official remote in `package.json` (`git+https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin.git`). Plugin development happens in that repository; this app bumps the dependency and runs `npm install` / `npx cap sync` after releases.
-
----
-
-## 1. What “parity” means here
-
-| Concern | Intended behavior |
-|--------|---------------------|
-| **Scheduling** | Dual schedule: prefetch job **before** notify time (app uses cron T−5 minutes), then user-visible notification at the chosen time. |
-| **API content** | Prefetch calls the **same Endorser semantics** as the Android host: **`plansLastUpdatedBetween`** (POST) with **starred plan IDs**, JWT auth, aggregated titles/bodies consistent with `TimeSafariNativeFetcher`. |
-| **Starred plans** | `updateStarredPlans({ planIds })` from the app must affect what the native prefetch queries. |
-| **Configure** | `configureNativeFetcher({ apiBaseUrl, activeDid, jwtToken, … })` supplies credentials the native layer uses for prefetch. |
-| **Lifecycle** | `cancelDualSchedule()` removes the dual prefetch + notify schedule without breaking the separate Daily Reminder. |
-
-Platform differences (iOS **BGTaskScheduler** is opportunistic; Android **alarms/WorkManager** can be more exact) mean **timing** may never be identical, but **API behavior and user-visible copy** should align.
-
----
-
-## 2. Current state: Android (this app)
-
-- **Host native fetcher:** `android/.../TimeSafariNativeFetcher.java` implements the plugin’s `NativeNotificationContentFetcher` and calls **`POST …/api/v2/report/plansLastUpdatedBetween`** using starred plan IDs (via plugin storage from `updateStarredPlans`).
-- **Registration:** `MainActivity` calls `DailyNotificationPlugin.setNativeFetcher(new TimeSafariNativeFetcher(this))`.
-- **Plugin (Android) — older notes:** Prior dual-schedule issues (native fetcher / fetch cron) are addressed in **plugin ≥ 3.0.0** (chained dual: notify after prefetch). Historical analysis: `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md`.
-
----
-
-## 3. Current state: iOS (this app + bundled plugin)
-
-### 3.1 This repository
-
-- **iOS native fetcher:** `ios/App/App/TimeSafariNativeFetcher.swift` implements `NativeNotificationContentFetcher` (Endorser `plansLastUpdatedBetween`, same prefs keys as Java). **`AppDelegate`** calls `DailyNotificationPlugin.registerNativeFetcher(TimeSafariNativeFetcher.shared)` at launch **before** any `configureNativeFetcher` from JS (see plugin `doc/CONSUMING_APP_HANDOFF_IOS_NATIVE_FETCHER_AND_CHAINED_DUAL.md` and **`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`**).
-- **JS/TS is already shared:** `nativeFetcherConfig.ts`, `dualScheduleConfig.ts`, `syncStarredPlansToNativePlugin.ts`, and `AccountViewView.vue` call the same APIs on both platforms.
-- **Info.plist** already lists `UIBackgroundModes` (fetch, processing) and `BGTaskSchedulerPermittedIdentifiers` for the plugin’s task IDs. Xcode **Signing & Capabilities** should still enable **Background fetch** and **Background processing** (see `doc/daily-notification-plugin-integration.md`).
-- **AppDelegate** posts `DailyNotificationDelivered` for foreground presentation—aligned with plugin rollover behavior.
-
-### 3.2 Bundled plugin (`node_modules/@timesafari/daily-notification-plugin`, iOS)
-
-Requires **plugin ≥ 3.0.0** (register native fetcher, chained dual, iOS `updateStarredPlans`). Version pinned in `ios/App/Podfile.lock` after `pod install`.
-
-- **`scheduleDualNotification` / `cancelDualSchedule`** — see plugin release notes; clean sync + `pod install` if you see `UNIMPLEMENTED` (`doc/plugin-feedback-ios-scheduleDualNotification.md`).
-- **`configureNativeFetcher`** — **requires** `DailyNotificationPlugin.registerNativeFetcher` first; the host Swift fetcher performs **`plansLastUpdatedBetween`** (plugin does not use in-plugin `offers` GET when a fetcher is registered—mirrors Android).
-- **`updateStarredPlans`** — implemented on iOS in current plugin; persists **`daily_notification_timesafari.starredPlanIds`** for the host fetcher.
-- **Chained dual** — user notification is armed **after** prefetch for that cycle (plugin); iOS remains subject to BG scheduling limits; see **§3.3**.
-
-### 3.3 Prefetch before notify (ordering, not cron)
-
-iOS has no system cron; the app/plugin may still **parse** cron to compute “next run” times. The hard part is **ordering**: if **prefetch** is driven by **`BGTaskScheduler`** (opportunistic) and **notify** by **`UNUserNotificationCenter`** at a fixed time **T**, those are **independent**. The OS can deliver the local notification at **T** while prefetch runs **after** **T** or not at all—so the awkward case (notify first, prefetch later, stale or fallback content) **can** happen. Two peer timers do **not** imply “fetch always completes before **T**.”
-
-To **enforce** prefetch-before-notify as a rule, use **chaining**, not two unrelated schedules:
-
-- After prefetch for that cycle **finishes** (success or explicit timeout policy), **then** schedule or **replace** the pending `UNNotificationRequest` for time **T** with the resolved title/body (or fallback). Until then, do not arm a user-visible notification that claims fresh API content.
-- **Tradeoffs:** If prefetch is late, the notification may be **late**; if prefetch never runs before a deadline, use **fallback** copy at **T** or skip—product choice.
-- **Parsing cron** remains useful to compute **T** and to decide when to **submit** BG work; **ordering** is a **pipeline** decision (fetch → cache → arm notify), not “BG at T−5 and UN at **T** both scheduled up front.”
-
-Plugin work item **§4A.3** should reflect this: document the chosen strategy (chained arm vs best-effort dual timer) and how it interacts with `relationship.contentTimeout` / fallback.
-
----
-
-## 4. Work breakdown
-
-### 4A. Plugin (`daily-notification-plugin`) — status (v3.x)
-
-Items below were the original gap list; **plugin ≥ 3.0.0** ships **iOS** `updateStarredPlans`, **`registerNativeFetcher`**, **chained dual** on iOS and Android, and Android dual-path fixes. Remaining work is **release coordination** (bump, sync, QA), not greenfield plugin implementation.
-
-1. **`updateStarredPlans` on iOS** — shipped in current plugin.
-
-2. **iOS `plansLastUpdatedBetween` / host fetcher** — shipped: host registers **`TimeSafariNativeFetcher`** (Swift); plugin does not duplicate Endorser logic when a fetcher is registered.
-
-3. **Dual schedule / chaining** — shipped (notify after prefetch; see plugin release notes and **§3.3**).
-
-4. **Android dual path** — chained dual + native fetcher alignment in current plugin (see `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` for historical context).
-
-5. **JWT pool / expiry (Phase B)**  
-   - **App:** Phase B is already implemented: `configureNativeFetcherIfReady()` passes `jwtTokens` from `mintBackgroundJwtTokenPool` on **both** iOS and Android (`src/services/notifications/nativeFetcherConfig.ts`).  
-   - **Android:** `TimeSafariNativeFetcher` selects a bearer from the pool for background requests (`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`).  
-   - **iOS:** The bundled plugin’s `configureNativeFetcher` **already accepts and persists** `jwtTokens` / `jwtTokenPoolJson`, and the in-plugin fetch path uses a bearer from the primary token or pool. What is **not** yet at parity with Android is **which API** that token is used for (`offers` GET vs `plansLastUpdatedBetween` + starred plans)—that falls under **§4A.2**, not “waiting for Phase B on iOS.”  
-   - **Expiry:** Re-calling `configureNativeFetcherIfReady` on foreground / Account (see `notification-from-api-call.md`) remains relevant on both platforms.
-
-### 4B. This app (crowd-funder-for-time-pwa) — after or alongside plugin changes
-
-1. **Bump `@timesafari/daily-notification-plugin`** to **≥ 3.0.0** via the git dependency in `package.json`, run `npm install`, `npx cap sync ios`, `cd ios/App && pod install`, clean build (`doc/plugin-feedback-ios-scheduleDualNotification.md`, **`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`**).
-2. **iOS native fetcher** — **Done:** `TimeSafariNativeFetcher.swift` + `registerNativeFetcher` in `AppDelegate` (see handoff doc).
-3. **Re-test** `syncStarredPlansToNativePlugin` on iOS; the helper may still catch `UNIMPLEMENTED` for older plugin binaries.
-4. **Xcode:** Confirm Background Modes capabilities match `Info.plist`.
-5. **QA:** Full matrix in `doc/notification-from-api-call.md` (enable/disable, empty starred list, JWT expiry, foreground/background); chained dual timing (notify after prefetch).
-
-### 4C. Related product bug (both platforms)
-
-- **`PushNotificationPermission.vue` vs New Activity:** Enabling New Activity can still schedule the **single** daily reminder by mistake; turning New Activity off may not cancel that reminder. See `doc/notification-new-activity-lay-of-the-land.md`. Fixing this is orthogonal to iOS/Android API parity but affects perceived “notifications behavior.”
-
----
-
-## 5. Reference map (this repo)
-
-| Topic | Document |
-|-------|-----------|
-| Plugin post-bump handoff (iOS fetcher + chained dual) | `doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md` |
-| Feature plan & file list | `doc/notification-from-api-call.md` |
-| Dual vs Daily Reminder confusion | `doc/notification-new-activity-lay-of-the-land.md` |
-| iOS `UNIMPLEMENTED` / PluginHeaders | `doc/plugin-feedback-ios-scheduleDualNotification.md` |
-| Android dual schedule + native fetcher | `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` |
-| Integration & Xcode | `doc/daily-notification-plugin-integration.md` |
-| Android host fetcher | `android/.../TimeSafariNativeFetcher.java`, `MainActivity.java` |
-
----
-
-## 6. Handoff to plugin repo (Cursor / isolated workspace)
-
-Use this section when **daily-notification-plugin** is open **without** the TimeSafari app tree, so implementers do not depend on paths that only exist in crowd-funder-for-time-pwa.
-
-### 6.1 Bring reference material into scope
-
-| Source (this app repo) | Why |
-|------------------------|-----|
-| `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` | **Canonical Endorser behavior** for New Activity: POST body, pagination, aggregation copy, prefs keys for starred IDs and `last_acked_jwt_id`. Copy or open alongside the plugin when implementing iOS fetch or `setNativeFetcher`. |
-| `src/services/notifications/dualScheduleConfig.ts` | Shape the app sends to `scheduleDualNotification` (`buildDualScheduleConfig`). |
-| `doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md` | Android plugin: dual path must call native fetcher at fetch cron. |
-| `doc/plugin-feedback-ios-scheduleDualNotification.md` | iOS `UNIMPLEMENTED` / PluginHeaders troubleshooting. |
-
-In the plugin repo itself, align with **`src/definitions.ts`** (`DualScheduleConfiguration`, `configureNativeFetcher`, `updateStarredPlans`) and **INTEGRATION_GUIDE** if present.
-
-### 6.2 HTTP / storage contract (match `TimeSafariNativeFetcher`)
-
-Implementations on **iOS** (in-plugin Swift or host `NativeNotificationContentFetcher`) should match this **unless** product explicitly changes:
-
-- **Method & path:** `POST` `{apiBaseUrl}/api/v2/report/plansLastUpdatedBetween` (no trailing slash mismatch on `apiBaseUrl`).
-- **Headers:** `Content-Type: application/json`, `Authorization: Bearer {token}` (token from `jwtToken` or **JWT pool** selection—see Java `selectBearerTokenForRequest`: UTC day mod pool size).
-- **JSON body:** `planIds` (array of strings, possibly empty), `afterId` (string; use `"0"` if none stored).
-- **Starred plans:** Android: SharedPreferences **`daily_notification_timesafari`** + key **`starredPlanIds`**. iOS (plugin + host): `UserDefaults.standard` key **`daily_notification_timesafari.starredPlanIds`** (JSON array string).
-- **Pagination:** After a successful response with non-empty `data`, update **`last_acked_jwt_id`** from the last row’s `jwtId` (item or nested `plan.jwtId`)—see Java `updateLastAckedJwtIdFromResponse`. iOS host (`TimeSafariNativeFetcher.swift`) persists **`daily_notification_timesafari.last_acked_jwt_id`** in `UserDefaults.standard`.
-- **Empty `data`:** Return **no** notification items (empty list); do not synthesize a “no updates” push from an empty result—Java returns empty `contents` when `data` is absent or empty.
-- **Non-empty `data`:** One aggregated `NotificationContent`: titles **Starred Project Update** / **Starred Project Updates**, bodies use typographic quotes around first project name and **has been updated.** / **+ N more have been updated.** (see Java `parseApiResponse`).
-
-### 6.3 Likely plugin touchpoints (maintenance / debugging)
-
-- **iOS:** `ios/Plugin/DailyNotificationPlugin.swift`, `DailyNotificationScheduleHelper.swift`, native fetcher registry, BG / UN paths.
-- **Android:** `DailyNotificationPlugin.kt`, fetch workers / `ScheduleHelper`—see dual-schedule feedback doc for history.
-
-### 6.4 Suggested order (plugin shipped ≥ 3.0.0)
-
-1. Tag / publish **`@timesafari/daily-notification-plugin`**.  
-2. **Consuming app:** bump, `npm install`, `npx cap sync`, `pod install`, QA (`doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`).
-
----
-
-## 7. Acceptance checklist (iOS vs Android product intent)
-
-- [ ] Prefetch uses **plansLastUpdatedBetween** (or host fetcher with identical behavior), not only `offers` GET.
-- [ ] **Starred plan IDs** from settings change what is queried (`updateStarredPlans` works on iOS).
-- [ ] Notification title/body match the **same rules** as Android for “starred project updates” (including empty updates).
-- [ ] `configureNativeFetcher` + JWT refresh story documented; re-config on foreground if needed (`notification-from-api-call.md`).
-- [ ] `cancelDualSchedule` clears dual prefetch/notify without leaving orphan schedules.
-- [ ] Understand and document **iOS timing** limitations vs Android for support/Help copy.
-- [ ] **Prefetch vs notify ordering** on iOS: chosen strategy (chained arm vs independent BG + UN) documented; avoids claiming fresh API content when prefetch has not run yet (**§3.3**).

doc/notification-debug-panel.md

@@ -1,234 +0,0 @@
-# Notification Debug Panel
-
-**Created:** 2026-07-07  
-**Updated:** 2026-07-22  
-**Audience:** Developers testing notification registration, refresh, and WAKEUP_PING flows on native (iOS/Android) dev builds.
-
-The **Notification Debug Panel** is a dev-only UI for exercising the same notification orchestration paths the production app uses: FCM token registration, backend refresh, wakeup handling, and local schedule inspection. It does not duplicate scheduling logic.
-
----
-
-## Notification API base URL
-
-Notification HTTP calls (`/notifications/register`, `/notifications/refresh`, `/debug/send-wakeup`, etc.) do **not** use `APP_SERVER`. They use a dedicated Notification API host, resolved at runtime by `getNotificationApiBaseUrl()` in `NotificationDebugConfig.ts`.
-
-### Configuration constants
-
-| Symbol | Location | Purpose |
-|--------|----------|---------|
-| `VITE_DEFAULT_NOTIFY_API_SERVER` | `.env.development` / `.env.test` / `.env.production` | Build-time default Notification API URL for that Vite mode (same pattern as other `VITE_DEFAULT_*` backends) |
-| `DEFAULT_NOTIFY_API_SERVER` | `src/constants/app.ts` | Runtime constant: `import.meta.env.VITE_DEFAULT_NOTIFY_API_SERVER \|\| AppString.PROD_NOTIFY_API_SERVER` |
-| `AppString.PROD_NOTIFY_API_SERVER` | `src/constants/app.ts` | Hardcoded production fallback: `https://notify-api.timesafari.app` |
-| `AppString.TEST_NOTIFY_API_SERVER` | `src/constants/app.ts` | Hardcoded test host: `https://test-notify-api.timesafari.app` (for explicit UI/debug use; not the automatic fallback) |
-
-Production, test, and development builds get different Notification API URLs from their respective `.env.*` files. Runtime request code always goes through `DEFAULT_NOTIFY_API_SERVER` (via `getNotificationApiBaseUrl()`), not by reading the env var directly at each call site.
-
-Typical values today:
-
-| Build / env file | `VITE_DEFAULT_NOTIFY_API_SERVER` |
-|------------------|----------------------------------|
-| `.env.production` | `https://notify-api.timesafari.app` |
-| `.env.test` | `https://test-notify-api.timesafari.app` |
-| `.env.development` | `https://test-notify-api.timesafari.app` |
-
-### URL resolution order
-
-`getNotificationApiBaseUrl()` selects the base URL in this order:
-
-1. **Debug Panel backend override** — `localStorage` key `notificationDebug.backendBaseUrl` (set via **Save Backend URL** or `setBackendBaseUrl()`)
-2. **`VITE_DEFAULT_NOTIFY_API_SERVER`** — baked into the build as part of `DEFAULT_NOTIFY_API_SERVER`
-3. **`AppString.PROD_NOTIFY_API_SERVER`** — hardcoded fallback when the env var is unset (`https://notify-api.timesafari.app`)
-
-Clearing the Debug Panel override (empty field + Save) returns the app to step 2 / 3 (`DEFAULT_NOTIFY_API_SERVER`). The override never changes auth behavior by itself.
-
-`APP_SERVER` / `VITE_APP_SERVER` remain for deep links and the main app web host only — not for notification API traffic.
-
----
-
-## Access
-
-1. Use a **non-production** build (for example `build:android:dev`, `build:ios:dev`, or `vite dev` with a non-`production` mode).
-2. Open **Account** → enable **Show All General Advanced Functions**.
-3. Open **Notification Debug Panel** (route `/dev/notifications`).
-
-On native platforms, grant notification permission when prompted so FCM token registration and the debug actions work.
-
----
-
-## Configuration (Backend Testing)
-
-Settings persist in `localStorage` via `NotificationDebugConfig.ts`:
-
-| Key | Default | Purpose |
-|-----|---------|---------|
-| `notificationDebug.backendBaseUrl` | *(unset — use `DEFAULT_NOTIFY_API_SERVER`)* | Override which notification server receives API calls |
-| `notificationDebug.testMode` | `true` | Sent in JSON request bodies (`testMode: true/false`) |
-| `notificationDebug.bypassAuth` | `false` | When `true`, omit JWT `Authorization` headers on notification API calls |
-
-All notification API requests (`/notifications/register`, `/notifications/refresh`, `/debug/send-wakeup`, etc.) obtain headers through `getNotificationApiHeaders()` in `notificationApiAuth.ts`.
-
-### Notification Backend URL
-
-Paste a base URL (no trailing slash) and tap **Save Backend URL**. This changes **only** which server the app calls (`getNotificationApiBaseUrl()`). It does **not** disable JWT authentication.
-
-Leave empty to use the configured build default (`DEFAULT_NOTIFY_API_SERVER`, from `VITE_DEFAULT_NOTIFY_API_SERVER` or `AppString.PROD_NOTIFY_API_SERVER`). The Debug Panel override still wins whenever a non-empty URL is saved.
-
-### Test Mode
-
-When enabled (default if never saved), register and refresh requests include `"testMode": true` in the JSON body. The backend can use this to return dev-friendly schedules or route test traffic separately from production.
-
-Test Mode is **independent of authentication**. It does not control whether `Authorization` headers are sent.
-
-### Skip JWT Authentication (Local Development Only)
-
-When **off** (default), the app resolves the active DID and sends `Authorization: Bearer …` on notification API calls.
-
-When **on**, requests include only `Content-Type: application/json` — for local servers (localhost or ngrok) that intentionally accept unauthenticated notification requests during development.
-
-Enable this **only** for local development backends that do not require JWT. Hosted shared test servers that require normal app authentication should leave this **off**.
-
-The panel **Backend Status** section shows the active URL, `testMode`, and `bypassAuth` values.
-
----
-
-## Recommended settings
-
-### Hosted test server
-
-Example: `https://test-notify-api.timesafari.app`
-
-On development and test builds, this host is already the default via `VITE_DEFAULT_NOTIFY_API_SERVER`. You can leave **Notification Backend URL** empty, or paste the same URL explicitly.
-
-| Setting | Value |
-|---------|-------|
-| **Notification Backend URL** | Empty (use default) or `https://test-notify-api.timesafari.app` |
-| **Test Mode** | **ON** (if the server expects `testMode: true`) |
-| **Skip JWT Authentication** | **OFF** |
-
-Ensure the app has an **active identity (DID)** with a valid endorser session so JWT headers can be built.
-
-### Local localhost / ngrok development
-
-Example: `https://abc123.ngrok-free.app` or `http://127.0.0.1:3000`
-
-| Setting | Value |
-|---------|-------|
-| **Notification Backend URL** | Your local or ngrok URL |
-| **Test Mode** | **ON** or **OFF** — match what your local **notification-wakeup-service** expects |
-| **Skip JWT Authentication** | **ON** only if the local server accepts unauthenticated requests; **OFF** if it validates JWT like production |
-
----
-
-## Backend Testing actions
-
-| Action | What it does |
-|--------|----------------|
-| **Register Token Now** | `POST {backend}/notifications/register` with current FCM token, `deviceId`, `platform`, and `testMode`. Forces re-registration (bypasses duplicate-token skip). |
-| **Refresh Notifications** | `POST {backend}/notifications/refresh` — same path used after a real WAKEUP_PING. Applies returned schedule to the native plugin. |
-| **Simulate WAKEUP_PING (Local)** | Calls the refresh API directly (no FCM). Quick test of backend URL + auth + refresh parsing without push delivery. |
-| **Send Real WAKEUP_PING** | `POST {backend}/debug/send-wakeup`; server sends a real FCM data message with `data.type = "WAKEUP_PING"`. Exercises backend → FCM → Capacitor listener → refresh → reschedule. Background the app before expecting delivery. |
-
-**Current FCM Token** displays the last token from Capacitor/Firebase registration. **Event Log** shows the last 100 `[Notifications]` messages (also visible in logcat / Xcode console on native).
-
----
-
-## Other panel sections
-
-| Section | Purpose |
-|---------|---------|
-| **Mock Timing Presets** | Interval for mock refresh timestamps (30 sec – 10 min). |
-| **Trigger Mock Refresh** | Applies synthetic future timestamps locally — no backend call. |
-| **Wakeup Ping Simulator** | Runs the production push handler with a synthetic `WAKEUP_PING` payload (no FCM, no backend). |
-| **Flood Test** | Runs 20 sequential mock refreshes (stress test). |
-| **Pending Notification Inspector** | Lists locally scheduled notifications (iOS; Android may show unavailable). |
-| **Clear Notifications** | Clears/cancels all plugin-scheduled notifications on native. |
-
----
-
-## Programmatic override (optional)
-
-From a WebView dev console (`chrome://inspect` on Android, Safari Web Inspector on iOS):
-
-```javascript
-import {
-  setBackendBaseUrl,
-  setTestMode,
-  setBypassAuth,
-  getNotificationApiBaseUrl,
-} from "@/services/notifications";
-
-setBackendBaseUrl("https://abc123.ngrok-free.app");
-setTestMode(true);
-setBypassAuth(true); // local dev only
-getNotificationApiBaseUrl();
-```
-
----
-
-## Troubleshooting
-
-### 401 Unauthorized (`registerToken failed: unauthorized`)
-
-**Likely causes:** JWT required but **Skip JWT Authentication** is off and the session is missing or expired; or JWT sent but the server rejected it.
-
-**Checks:**
-
-1. Panel **Backend Status** → `bypassAuth: false` for hosted servers.
-2. App has an active DID and endorser login.
-3. Event Log: look for `Using authenticated notification request` vs `Using debug unauthenticated notification request`.
-4. For hosted test server: keep **Skip JWT Authentication** **OFF**.
-
-**Fixes:** Sign in / restore identity; refresh endorser session; for local ngrok without JWT support, enable **Skip JWT Authentication**.
-
-### `registerToken auth unavailable` / `Waiting for auth before registration`
-
-The app deferred registration because JWT could not be built (no active DID or empty token) and **Skip JWT Authentication** is **off**.
-
-**Fixes:** Complete identity setup in the app, or enable **Skip JWT Authentication** only for an intentionally unauthenticated local backend.
-
-### Failed to fetch / network error
-
-**Likely causes:** Backend down, wrong URL, stale ngrok tunnel, device offline, or TLS/certificate issues.
-
-**Checks:** Panel **Backend Status** URL; `curl -sS "$URL/health"` from your machine; ngrok inspect UI for incoming requests.
-
-**Fixes:** Restart backend and ngrok; **Save Backend URL** with the current HTTPS forwarding URL (no trailing slash).
-
-### Backend unreachable / no requests in ngrok
-
-Same as above. Confirm the **Active** URL in the panel matches your running tunnel or local server port.
-
-### Register succeeds but Send Real WAKEUP_PING does not trigger refresh
-
-**Real WAKEUP_PING success** only means the backend accepted the wakeup request and attempted FCM delivery. Missing `pushNotificationReceived` / `Refresh completed (WAKEUP_PING)` indicates an FCM delivery or background execution issue — not necessarily a bad wakeup API call.
-
-**Checks:** App backgrounded (not force-stopped); FCM token matches registration; **Simulate WAKEUP_PING (Local)** works (isolates FCM from refresh API).
-
-See platform-specific guides for extended ngrok and FCM workflows:
-
-- [local-android-testing-ngrok.md](./local-android-testing-ngrok.md)
-- [local-ios-testing-ngrok.md](./local-ios-testing-ngrok.md)
-
----
-
-## Key source files
-
-| File | Purpose |
-|------|---------|
-| `src/constants/app.ts` | `DEFAULT_NOTIFY_API_SERVER`, `PROD_NOTIFY_API_SERVER`, `TEST_NOTIFY_API_SERVER` |
-| `src/components/dev/NotificationDebugPanel.vue` | Dev UI |
-| `src/services/notifications/NotificationDebugConfig.ts` | Base URL resolution, testMode, bypassAuth persistence |
-| `src/services/notifications/notificationApiAuth.ts` | JWT vs unauthenticated headers |
-| `src/services/notifications/notificationApiDebugMode.ts` | Auth bypass gate |
-| `src/services/notifications/NotificationDebugService.ts` | Panel action handlers |
-| `src/services/notifications/NotificationService.ts` | `POST /notifications/register` |
-| `src/services/notifications/NativeNotificationService.ts` | `POST /notifications/refresh`, WAKEUP_PING handler |
-
----
-
-## Related docs
-
-- [notification-system-overview.md](./notification-system-overview.md)
-- [notification-from-api-call.md](./notification-from-api-call.md)
-- [local-android-testing-ngrok.md](./local-android-testing-ngrok.md)
-- [local-ios-testing-ngrok.md](./local-ios-testing-ngrok.md)

doc/notification-from-api-call.md

@@ -1,108 +0,0 @@
-# New Activity Notification (API-Driven Daily Message)
-
-**Purpose:** Integrate the daily-notification-plugin’s second feature—the **daily, API-driven message**—into the crowd-funder (TimeSafari) app. The first feature (daily static reminder) is already integrated; this document covers the plan, completed work, and remaining tasks for the API-driven flow.
-
-**References:**
-
-- Plugin: `daily-notification-plugin` (INTEGRATION_GUIDE.md, definitions.ts)
-- Alignment outline: `doc/daily-notification-alignment-outline.md`
-- Help copy: `HelpNotificationTypesView.vue` (“New Activity Notifications”)
-
----
-
-## Plan Summary
-
-The API-driven flow:
-
-1. **Prefetch** – Shortly before the user’s chosen time, the plugin runs a background job that calls the Endorser.ch API (e.g. `plansLastUpdatedBetween`, and optionally offers endpoints) using credentials supplied by the app.
-2. **Cache** – Fetched content is stored in the plugin’s cache.
-3. **Notify** – At the chosen time, the user sees a notification whose title/body come from that content (or a fallback).
-
-The app must:
-
-- **Configure the native fetcher** with `apiBaseUrl`, `activeDid`, and a JWT so the plugin’s background workers can call the API.
-- **Implement the native fetcher** (or register an implementation) so the plugin can perform the actual HTTP requests and parse responses into notification content.
-- **Sync starred plan IDs** to the plugin via `updateStarredPlans` so the fetcher knows which plans to query.
-- **Expose UI** to enable/disable the “New Activity” notification and choose a time, and call `scheduleDualNotification` / `cancelDualSchedule` accordingly.
-
----
-
-## Tasks Finished
-
-- **Configure native fetcher on startup and identity**
-  - Added `configureNativeFetcherIfReady()` in `src/services/notifications/nativeFetcherConfig.ts` (reads `activeDid` and `apiServer` from DB, gets JWT via `getHeaders(did)`, calls `DailyNotification.configureNativeFetcher()`).
-  - Called from `main.capacitor.ts` after the 2s delay (with deep link registration).
-  - Called from `AccountViewView.initializeState()` when on native and `activeDid` is set; when New Activity is enabled, also calls `updateStarredPlans(settings.starredPlanHandleIds)`.
-- **Implement real API calls in Android native fetcher**
-  - `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` implements `NativeNotificationContentFetcher`: POST to `/api/v2/report/plansLastUpdatedBetween` with `planIds` (from SharedPreferences `daily_notification_timesafari` / `starredPlanIds`) and `afterId`; when `data` is non-empty, builds **one** aggregated `NotificationContent` (title **Starred Project Update** or **Starred Project Updates**, body from `plan.name` with typographic quotes, then `has been updated.` or `+ N more have been updated.`); when `data` is empty, returns an empty list (no “no updates” notification); updates `last_acked_jwt_id` for pagination when content is returned.
-  - Registered in `MainActivity.onCreate()` via `DailyNotificationPlugin.setNativeFetcher(new TimeSafariNativeFetcher(this))`.
-- **Sync starred plan IDs**
-  - Shared helper `syncStarredPlansToNativePlugin(planIds)` in `src/services/notifications/syncStarredPlansToNativePlugin.ts` (exported from `src/services/notifications/index.ts`) calls `DailyNotification.updateStarredPlans` on native only; ignores `UNIMPLEMENTED`.
-  - When user enables New Activity, `scheduleNewActivityDualNotification()` uses the helper with `settings.starredPlanHandleIds ?? []`.
-  - When Account view loads and New Activity is on, `initializeState()` uses the helper with the same list.
-  - When the user stars or unstars on a project (`ProjectViewView.toggleStar`), after a successful settings save, the helper runs if `notifyingNewActivityTime` is set so prefetch sees the current list without reopening Account.
-- **Dual schedule config and scheduling**
-  - Added `src/services/notifications/dualScheduleConfig.ts`: `timeToCron()`, `timeToCronFiveMinutesBefore()`, `buildDualScheduleConfig({ notifyTime, title?, body? })` (contentFetch 5 min before, userNotification at chosen time).
-  - When user enables New Activity and picks a time, app calls `DailyNotification.scheduleDualNotification({ config })` with this config.
-  - When user disables New Activity, app calls `DailyNotification.cancelDualSchedule()`.
-- **UI for New Activity notification**
-  - Unhid the “New Activity Notification” block in `AccountViewView.vue` (toggle + accessibility).
-  - Enable flow: time dialog → save settings → on native, `scheduleNewActivityDualNotification(timeText)` (configure fetcher, updateStarredPlans, scheduleDualNotification).
-  - Disable flow: on native, `cancelDualSchedule()` then save and clear settings.
-  - Added `starredPlanHandleIds` to `AccountSettings` in `interfaces/accountView.ts`.
-- **Exports**
-  - `src/services/notifications/index.ts` exports `configureNativeFetcherIfReady`, `syncStarredPlansToNativePlugin`, `buildDualScheduleConfig`, `timeToCron`, `timeToCronFiveMinutesBefore`, and `DualScheduleConfigInput`.
-
----
-
-## Checklist of Remaining Tasks
-
-### iOS
-
-**Parity outline (API, starred plans, plugin vs app work):** See **`doc/new-activity-notifications-ios-android-parity.md`**.
-
-- **Confirm iOS native fetcher / dual schedule**  
-Plugin exposes `configureNativeFetcher` on iOS. Confirm whether the plugin expects an iOS-specific native fetcher registration (similar to Android’s `setNativeFetcher`) and, if so, register a TimeSafari fetcher implementation for iOS so API-driven notifications work on iPhone.
-- **Verify dual schedule on iOS**  
-Test `scheduleDualNotification` and `cancelDualSchedule` on iOS; ensure content fetch and user notification fire at the expected times and that foreground/background behavior matches expectations.
-
-### Testing and hardening
-
-- **Test full flow on Android**  
-Enable New Activity, set time, wait for prefetch and notification (or use a short rollover for testing). Confirm notification shows with API-derived or fallback content.
-- **Test full flow on iOS**  
-Same as Android: enable, set time, verify prefetch and notification delivery and content.
-- **Test with no starred plans**  
-Enable New Activity with empty `starredPlanHandleIds`; confirm no crash; the native fetcher returns no Endorser-derived items when there is nothing to query or no new rows (see `TimeSafariNativeFetcher`).
-- **Test JWT expiry**  
-Ensure behavior when the token passed to `configureNativeFetcher` has expired (e.g. app in background for a long time); document or implement refresh (e.g. re-call `configureNativeFetcherIfReady` on foreground or when opening Account).
-
-### Optional enhancements
-
-- **Offers endpoints**  
-Extend `TimeSafariNativeFetcher` (and any iOS fetcher) to call offers endpoints (e.g. `offers`, `offersToPlansOwnedByMe`) and merge with project-update content for richer notifications.
-- **Documentation**  
-Add a short “New Activity notifications” section to BUILDING.md or a user-facing help page describing how the feature works and how to troubleshoot (e.g. no notification, wrong content, JWT/API errors).
-
----
-
-## File Reference
-
-
-| Area                   | Files                                                                   |
-| ---------------------- | ----------------------------------------------------------------------- |
-| Fetcher config         | `src/services/notifications/nativeFetcherConfig.ts`                     |
-| Starred list → plugin  | `src/services/notifications/syncStarredPlansToNativePlugin.ts`          |
-| Dual schedule config   | `src/services/notifications/dualScheduleConfig.ts`                      |
-| Notification exports   | `src/services/notifications/index.ts`                                   |
-| Startup                | `src/main.capacitor.ts`                                                 |
-| Account UI and flow    | `src/views/AccountViewView.vue`                                         |
-| Project star / unstar  | `src/views/ProjectViewView.vue` (`toggleStar`)                          |
-| Settings type          | `src/interfaces/accountView.ts`                                         |
-| Android native fetcher | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
-| Android registration   | `android/app/src/main/java/app/timesafari/MainActivity.java`            |
-| iOS native fetcher     | `ios/App/App/TimeSafariNativeFetcher.swift`                              |
-| iOS registration       | `ios/App/App/AppDelegate.swift` (`DailyNotificationPlugin.registerNativeFetcher`) |
-| Plugin 3.x handoff     | `doc/consuming-app-handoff-ios-native-fetcher-chained-dual.md`           |
-
-

doc/notification-integration-changes-outline.md

@@ -1,412 +0,0 @@
-# Notification Integration Changes - Implementation Outline
-
-**Date**: 2026-01-23  
-**Purpose**: Detailed outline of changes needed to integrate DailyNotificationPlugin with UI
-
----
-
-## Overview
-
-This document outlines all changes required to integrate the DailyNotificationPlugin with the existing notification UI, making it work seamlessly on both native (iOS/Android) and web platforms.
-
-**Estimated Complexity**: Medium  
-**Estimated Files Changed**: 3-4 files  
-**Breaking Changes**: None (backward compatible)
-
----
-
-## Change Summary
-
-| File | Changes | Complexity | Risk |
-|------|---------|------------|------|
-| `PushNotificationPermission.vue` | Add platform detection, native flow | Medium | Low |
-| `AccountViewView.vue` | Platform detection in toggles, hide push server on native | Low | Low |
-| `WebPushNotificationService.ts` | Complete stub implementation (optional) | Medium | Low |
-
----
-
-## Detailed Changes
-
-### 1. PushNotificationPermission.vue
-
-**File**: `src/components/PushNotificationPermission.vue`  
-**Current Lines**: ~656 lines  
-**Estimated New Lines**: +50-80 lines  
-**Complexity**: Medium
-
-#### Changes Required
-
-**A. Add Imports** (Top of script section)
-```typescript
-import { Capacitor } from "@capacitor/core";
-import { NotificationService } from "@/services/notifications";
-```
-
-**B. Add Platform Detection Property**
-```typescript
-// Add to class properties
-private get isNativePlatform(): boolean {
-  return Capacitor.isNativePlatform();
-}
-```
-
-**C. Modify `open()` Method** (Lines 170-258)
-- **Current**: Always initializes web push (VAPID key, service worker)
-- **Change**: Add platform check at start
-  - If native: Skip VAPID/service worker, show UI immediately
-  - If web: Keep existing logic
-
-**D. Modify `turnOnNotifications()` Method** (Lines 393-499)
-- **Current**: Web push subscription flow
-- **Change**: Split into two paths:
-  - **Native path**: Use `NotificationService.getInstance()` → `requestPermissions()` → `scheduleDailyNotification()`
-  - **Web path**: Keep existing logic
-
-**E. Add New Method: `turnOnNativeNotifications()`**
-- Request permissions via `NotificationService`
-- Convert time input (AM/PM) to 24-hour format (HH:mm)
-- Call `scheduleDailyNotification()` with proper options
-- Save to settings
-- Call callback with success/time/message
-
-**F. Update `handleTurnOnNotifications()` Method** (Line 643)
-- Add platform check
-- Route to `turnOnNativeNotifications()` or `turnOnNotifications()` based on platform
-
-**G. Update Computed Properties**
-- `isSystemReady`: For native, return `true` immediately (no VAPID needed)
-- `canShowNotificationForm`: For native, return `true` immediately
-
-**H. Update Template** (Optional - for better UX)
-- Add platform-specific messaging if desired
-- Native: "Notifications will be scheduled on your device"
-- Web: Keep existing messaging
-
-#### Code Structure Preview
-
-```typescript
-async open(pushType: string, callback?: ...) {
-  this.callback = callback || this.callback;
-  this.isVisible = true;
-  this.pushType = pushType;
-  
-  // Platform detection
-  if (this.isNativePlatform) {
-    // Native: No VAPID/service worker needed
-    this.serviceWorkerReady = true; // Fake it for UI
-    this.vapidKey = "native"; // Placeholder
-    return; // Skip web push initialization
-  }
-  
-  // Existing web push initialization...
-  // (keep all existing code)
-}
-
-async turnOnNotifications() {
-  if (this.isNativePlatform) {
-    return this.turnOnNativeNotifications();
-  }
-  // Existing web push logic...
-}
-
-private async turnOnNativeNotifications(): Promise<void> {
-  const service = NotificationService.getInstance();
-  
-  // Request permissions
-  const granted = await service.requestPermissions();
-  if (!granted) {
-    // Handle permission denial
-    return;
-  }
-  
-  // Convert time to 24-hour format
-  const time24h = this.convertTo24HourFormat();
-  
-  // Determine title and body based on pushType
-  const title = this.pushType === this.DAILY_CHECK_TITLE 
-    ? "Daily Check-In" 
-    : "Daily Reminder";
-  const body = this.pushType === this.DIRECT_PUSH_TITLE
-    ? this.messageInput
-    : "Time to check your TimeSafari activity";
-  
-  // Schedule notification
-  const success = await service.scheduleDailyNotification({
-    time: time24h,
-    title,
-    body,
-    priority: 'normal'
-  });
-  
-  if (success) {
-    // Save to settings
-    const timeText = this.notificationTimeText;
-    await this.$saveSettings({
-      [this.pushType === this.DAILY_CHECK_TITLE 
-        ? 'notifyingNewActivityTime' 
-        : 'notifyingReminderTime']: timeText,
-      ...(this.pushType === this.DIRECT_PUSH_TITLE && {
-        notifyingReminderMessage: this.messageInput
-      })
-    });
-    
-    // Call callback
-    this.callback(true, timeText, this.messageInput);
-  }
-}
-
-private convertTo24HourFormat(): string {
-  const hour = parseInt(this.hourInput);
-  const minute = parseInt(this.minuteInput);
-  
-  let hour24 = hour;
-  if (!this.hourAm && hour !== 12) {
-    hour24 = hour + 12;
-  } else if (this.hourAm && hour === 12) {
-    hour24 = 0;
-  }
-  
-  return `${hour24.toString().padStart(2, '0')}:${minute.toString().padStart(2, '0')}`;
-}
-```
-
-#### Testing Considerations
-- Test on iOS device
-- Test on Android device
-- Test on web (should still work as before)
-- Test permission denial flow
-- Test time conversion (AM/PM → 24-hour)
-
----
-
-### 2. AccountViewView.vue
-
-**File**: `src/views/AccountViewView.vue`  
-**Current Lines**: 2124 lines  
-**Estimated New Lines**: +20-30 lines  
-**Complexity**: Low
-
-#### Changes Required
-
-**A. Add Import** (Top of script section, around line 739)
-```typescript
-import { Capacitor } from "@capacitor/core";
-```
-
-**B. Add Computed Property** (In class, around line 888)
-```typescript
-private get isNativePlatform(): boolean {
-  return Capacitor.isNativePlatform();
-}
-```
-
-**C. Modify Notification Toggle Methods** (Lines 1134-1202)
-
-**`showNewActivityNotificationChoice()`** (Lines 1134-1158)
-- **Current**: Always uses `PushNotificationPermission` component
-- **Change**: Add platform check
-  - If native: Use `NotificationService` directly (or still use component - it will handle platform)
-  - If web: Keep existing logic
-  - **Note**: Since we're updating `PushNotificationPermission` to handle both, this might not need changes, but we could add direct native path for cleaner code
-
-**`showReminderNotificationChoice()`** (Lines 1171-1202)
-- Same as above
-
-**D. Conditionally Hide Push Server Setting** (Lines 506-549)
-- Wrap the entire "Notification Push Server" section in `v-if="!isNativePlatform"`
-- This hides it on iOS/Android where it's not needed
-
-**E. Update Status Display** (Optional)
-- When showing notification status, could add platform indicator
-- "Native notification scheduled" vs "Web push subscription active"
-
-#### Code Structure Preview
-
-```typescript
-// Add computed property
-private get isNativePlatform(): boolean {
-  return Capacitor.isNativePlatform();
-}
-
-// In template, wrap push server section:
-<section v-if="!isNativePlatform" id="sectionPushServer">
-  <h2 class="text-slate-500 text-sm font-bold mb-2">
-    Notification Push Server
-  </h2>
-  <!-- ... existing push server UI ... -->
-</section>
-
-// Optional: Update notification choice methods
-async showNewActivityNotificationChoice(): Promise<void> {
-  if (!this.notifyingNewActivity) {
-    // Component now handles platform detection, so this can stay the same
-    // OR we could add direct native path here for cleaner separation
-    (this.$refs.pushNotificationPermission as PushNotificationPermission)
-      .open(DAILY_CHECK_TITLE, async (success: boolean, timeText: string) => {
-        // ... existing callback ...
-      });
-  } else {
-    // ... existing turn-off logic ...
-  }
-}
-```
-
-#### Testing Considerations
-- Verify push server section hidden on iOS
-- Verify push server section hidden on Android
-- Verify push server section visible on web
-- Test notification toggles work on all platforms
-
----
-
-### 3. WebPushNotificationService.ts (Optional Enhancement)
-
-**File**: `src/services/notifications/WebPushNotificationService.ts`  
-**Current Lines**: 213 lines  
-**Estimated New Lines**: +100-150 lines  
-**Complexity**: Medium  
-**Priority**: Low (can be done later)
-
-#### Changes Required
-
-**A. Complete `scheduleDailyNotification()` Implementation**
-- Extract logic from `PushNotificationPermission.vue`
-- Subscribe to push service
-- Send subscription to server
-- Return success status
-
-**B. Complete `cancelDailyNotification()` Implementation**
-- Get current subscription
-- Unsubscribe from push service
-- Notify server to stop sending
-
-**C. Complete `getStatus()` Implementation**
-- Check settings for `notifyingNewActivityTime` / `notifyingReminderTime`
-- Check service worker subscription status
-- Return combined status
-
-**Note**: This is optional because `PushNotificationPermission.vue` already handles web push. Completing this would allow using `NotificationService` directly for web too, but it's not required for the integration to work.
-
----
-
-## Implementation Order
-
-### Phase 1: Core Integration (Required)
-1. ✅ Update `PushNotificationPermission.vue` with platform detection
-2. ✅ Update `AccountViewView.vue` to hide push server on native
-3. ✅ Test on native platforms
-
-### Phase 2: Polish (Optional)
-4. Complete `WebPushNotificationService.ts` implementation
-5. Add platform-specific UI messaging
-6. Add status indicators
-
----
-
-## Risk Assessment
-
-### Low Risk Changes
-- ✅ Adding platform detection (read-only check)
-- ✅ Conditionally hiding UI elements
-- ✅ Adding new code paths (not modifying existing)
-
-### Medium Risk Changes
-- ⚠️ Modifying `turnOnNotifications()` flow (but we're adding, not replacing)
-- ⚠️ Time format conversion (need to test edge cases)
-
-### Mitigation Strategies
-1. **Backward Compatibility**: All changes are additive - existing web push flow remains unchanged
-2. **Feature Flags**: Could add feature flag to enable/disable native notifications
-3. **Gradual Rollout**: Test on one platform first (e.g., Android), then iOS
-4. **Fallback**: If native service fails, could fall back to showing error message
-
----
-
-## Testing Checklist
-
-### Functional Testing
-- [ ] Native iOS: Request permissions → Schedule notification → Verify scheduled
-- [ ] Native Android: Request permissions → Schedule notification → Verify scheduled
-- [ ] Web: Existing flow still works (no regression)
-- [ ] Permission denial: Shows appropriate error message
-- [ ] Time conversion: AM/PM correctly converts to 24-hour format
-- [ ] Both notification types: Daily Check and Direct Push work on native
-- [ ] Settings persistence: Times saved correctly to database
-
-### UI Testing
-- [ ] Push server setting hidden on iOS
-- [ ] Push server setting hidden on Android
-- [ ] Push server setting visible on web
-- [ ] Notification toggles work on all platforms
-- [ ] Time picker UI works on native (same as web)
-
-### Edge Cases
-- [ ] 12:00 AM conversion (should be 00:00)
-- [ ] 12:00 PM conversion (should be 12:00)
-- [ ] Invalid time input handling
-- [ ] App restart: Notifications still scheduled
-- [ ] Device reboot: Notifications still scheduled (Android)
-
----
-
-## Dependencies
-
-### Required
-- ✅ `@capacitor/core` - Already in project
-- ✅ `@timesafari/daily-notification-plugin` - Already installed
-- ✅ `NotificationService` - Already created
-
-### No New Dependencies Needed
-
----
-
-## Estimated Effort
-
-| Task | Time Estimate |
-|------|---------------|
-| Update PushNotificationPermission.vue | 2-3 hours |
-| Update AccountViewView.vue | 30 minutes - 1 hour |
-| Testing on iOS | 1-2 hours |
-| Testing on Android | 1-2 hours |
-| Bug fixes & polish | 1-2 hours |
-| **Total** | **5-10 hours** |
-
----
-
-## Rollback Plan
-
-If issues arise:
-
-1. **Quick Rollback**: Revert changes to `PushNotificationPermission.vue` and `AccountViewView.vue`
-2. **Partial Rollback**: Keep platform detection but disable native path (feature flag)
-3. **No Data Migration Needed**: Settings structure unchanged
-
----
-
-## Questions to Consider
-
-1. **Should we keep using `PushNotificationPermission` component for native, or create separate native flow?**
-   - **Recommendation**: Keep using component (simpler, less code duplication)
-
-2. **Should we show different UI messaging for native vs web?**
-   - **Recommendation**: Optional enhancement, not required for MVP
-
-3. **Should we complete `WebPushNotificationService` now or later?**
-   - **Recommendation**: Later (not blocking, existing component works)
-
-4. **How to handle notification cancellation on native?**
-   - **Recommendation**: Use `NotificationService.cancelDailyNotification()` in existing turn-off logic
-
----
-
-## Next Steps After Implementation
-
-1. Update documentation with platform-specific instructions
-2. Add error handling for edge cases
-3. Consider adding notification status display in UI
-4. Test on real devices (critical for native notifications)
-5. Monitor for any platform-specific issues
-
----
-
-**Last Updated**: 2026-01-23

doc/notification-new-activity-lay-of-the-land.md

@@ -1,250 +0,0 @@
-# Lay of the Land: API-Driven Daily Message (New Activity) and Web-Push Confusion
-
-**Purpose:** Shareable analysis of the New Activity (API-driven daily message) implementation and the root cause of “always fires / can’t be turned off.” For discussion with teammates.
-
-**Related:** `doc/notification-from-api-call.md` (plan and progress), teammate note about web-push confusion and possibly removing that logic.
-
----
-
-## 1. Two Separate Notification Features
-
-There are **two** distinct native notification flows that both go through the same UI component:
-
-| Feature | Plugin API | Purpose |
-|--------|------------|--------|
-| **Daily Reminder** | `scheduleDailyNotification` / `cancelDailyReminder` | Single daily alarm, static title/body (user’s message). |
-| **New Activity** (API-driven) | `scheduleDualNotification` / `cancelDualSchedule` | Prefetch from API 5 min before, then notify at chosen time with API or fallback content. |
-
-- **Daily Reminder** is driven from AccountViewView’s “Daily Reminder” toggle; on native it uses `NotificationService.getInstance().scheduleDailyNotification()` / `cancelDailyNotification()` (backed by `NativeNotificationService` and a single `reminderId`: `"daily_timesafari_reminder"`).
-- **New Activity** is intended to be driven only by `scheduleNewActivityDualNotification()` / `cancelDualSchedule()` in AccountViewView (dual schedule only).
-
-So: one feature = single schedule (reminder), the other = dual schedule (prefetch + notify). They are different plugin APIs and different lifecycle (enable/disable) handling.
-
----
-
-## 2. Where the Bug Comes From: One Dialog, Two Behaviors
-
-**New Activity** reuses the same dialog as Daily Reminder: **`PushNotificationPermission.vue`**.
-
-- When the user turns **New Activity** on from AccountViewView:
-  - AccountViewView opens this dialog with `DAILY_CHECK_TITLE` and a callback that, on success, calls `scheduleNewActivityDualNotification(timeText)` on native.
-  - The dialog does **not** receive `skipSchedule: true` for this flow (only the “edit reminder” flow does).
-
-So when the user clicks “Turn on Daily Reminder” in the dialog for **New Activity**:
-
-1. **PushNotificationPermission** (native path) runs `turnOnNativeNotifications()` and always calls:
-   - `service.scheduleDailyNotification({ time, title: "Daily Check-In", body: "Time to check your TimeSafari activity", ... })`
-   - i.e. it schedules the **single** daily reminder (plugin’s `scheduleDailyNotification`), using the same `reminderId` as Daily Reminder (`"daily_timesafari_reminder"`).
-2. Then the callback runs and AccountViewView calls **`scheduleNewActivityDualNotification(timeText)`**, which calls the plugin’s **`scheduleDualNotification`**.
-
-Result:
-
-- **Two schedules** are created when enabling New Activity:
-  - One **single** reminder (wrong for New Activity): static “Daily Check-In” message, same ID as Daily Reminder.
-  - One **dual** schedule (correct): prefetch + notify with API/fallback content.
-- When the user turns **New Activity** off, AccountViewView only calls **`cancelDualSchedule()`**. It never calls `cancelDailyNotification()` (or equivalent) for the single reminder.
-- So the **single** reminder stays scheduled and keeps firing at the chosen time. That’s the notification that “always fires” and “can’t be turned off.”
-
-So the “huge problem with confusion with the web-push” is really: **the same dialog and the same “Turn on” path are used for both Daily Reminder and New Activity, but the dialog always schedules the single daily reminder on native**, while New Activity is supposed to use only the dual schedule. That mixing is what makes the wrong schedule stick and not be cancellable from the New Activity toggle.
-
----
-
-## 3. Key Files and Flows
-
-- **`src/components/PushNotificationPermission.vue`**
-  - Shared dialog for both “Daily Reminder” and “New Activity” (via `pushType` = `DIRECT_PUSH_TITLE` vs `DAILY_CHECK_TITLE`).
-  - On native it always uses `NotificationService.getInstance().scheduleDailyNotification(...)` (single reminder) and does not branch on “New Activity” to skip scheduling or to call the dual API.
-  - Saves `notifyingNewActivityTime` when `pushType === DAILY_CHECK_TITLE` (lines 834–836). So the dialog both schedules the wrong thing and persists settings for New Activity.
-
-- **`src/views/AccountViewView.vue`**
-  - **Daily Reminder:** toggle opens same dialog with `DIRECT_PUSH_TITLE`; on native, disable path calls `service.cancelDailyNotification()`.
-  - **New Activity:** toggle opens same dialog with `DAILY_CHECK_TITLE`; on success callback calls `scheduleNewActivityDualNotification(timeText)`; on disable only calls `DailyNotification.cancelDualSchedule()`.
-  - `initializeState()`: on native with `activeDid`, calls `configureNativeFetcherIfReady(activeDid)` and, if New Activity is on, `updateStarredPlans(...)`. It does **not** re-call `scheduleNewActivityDualNotification` on load (so no double dual-schedule from here).
-
-- **`src/services/notifications/NativeNotificationService.ts`**
-  - Single reminder only: `scheduleDailyNotification` → plugin `scheduleDailyNotification` with `id: this.reminderId` (`"daily_timesafari_reminder"`); `cancelDailyNotification` → `cancelDailyReminder({ reminderId })`. No dual API here.
-
-- **`src/services/notifications/nativeFetcherConfig.ts`**
-  - Only configures the plugin for API calls (JWT, apiBaseUrl, activeDid). No scheduling.
-
-- **`src/services/notifications/dualScheduleConfig.ts`**
-  - Builds config for `scheduleDualNotification` (contentFetch 5 min before, userNotification at notify time). Used only from AccountViewView’s `scheduleNewActivityDualNotification`.
-
-- **`src/main.capacitor.ts`**
-  - Imports the daily-notification plugin; after a 2s delay calls `configureNativeFetcherIfReady()`. No scheduling; only fetcher config.
-
-So: the “always fires / can’t turn off” behavior is from the **single** reminder created in `PushNotificationPermission` for New Activity and never cancelled when New Activity is turned off. The “confusion with web-push” is the reuse of the same dialog and the same native “schedule single reminder” path for both features.
-
----
-
-## 4. Plugin Usage Summary
-
-- **Single daily reminder (Daily Reminder):**
-  - Scheduled/cancelled via `NativeNotificationService.scheduleDailyNotification` / `cancelDailyNotification` → plugin `scheduleDailyNotification` / `cancelDailyReminder` with one `reminderId`.
-- **Dual schedule (New Activity):**
-  - Scheduled/cancelled only in AccountViewView via `DailyNotification.scheduleDualNotification` / `cancelDualSchedule` (and `configureNativeFetcherIfReady` + `updateStarredPlans` as per doc).
-- **Fetcher config (New Activity):**
-  - `configureNativeFetcherIfReady()` from main.capacitor and from AccountViewView `initializeState` / `scheduleNewActivityDualNotification`; no scheduling by itself.
-
----
-
-## 5. Root Cause (Concise)
-
-- **Single code path in PushNotificationPermission** for native: it always schedules the **single** daily reminder, regardless of `pushType` (Daily Reminder vs New Activity).
-- For **New Activity**, that creates an extra, wrong schedule (single reminder) in addition to the correct dual schedule.
-- **Disable path for New Activity** only calls `cancelDualSchedule()` and never cancels the single reminder, so that reminder keeps firing and appears as “always fires” and “can’t be turned off.”
-
----
-
-## 6. Proper Fix: Options and Detail
-
-A fix should ensure that (1) enabling New Activity creates only the dual schedule, and (2) disabling New Activity removes every schedule that was created for it. Below are concrete options and implementation notes.
-
-### 6.1 Option A: Don’t schedule the single reminder when the dialog is for New Activity (recommended)
-
-**Idea:** On native, when the dialog is opened for **New Activity** (`pushType === DAILY_CHECK_TITLE`), the dialog should **not** call `scheduleDailyNotification`. Only the callback in AccountViewView should run, and it already calls `scheduleNewActivityDualNotification(timeText)`, which uses the dual API only.
-
-**Where:** `PushNotificationPermission.vue`, inside `turnOnNativeNotifications()`.
-
-**Implementation sketch:**
-
-- After requesting permissions and before calling `service.scheduleDailyNotification(...)`, branch on `pushType` and platform:
-  - If native **and** `pushType === this.DAILY_CHECK_TITLE`: skip the `scheduleDailyNotification` call entirely. Still run the rest of the flow (e.g. build `timeText`, save settings if desired, call `callback(true, timeText, ...)`). AccountViewView’s callback will then call `scheduleNewActivityDualNotification(timeText)` and that is the only schedule created for New Activity.
-  - Otherwise (web, or Daily Reminder on native): keep current behavior and call `scheduleDailyNotification` as today.
-
-**Pros:** Single source of truth for “what is scheduled for New Activity” (dual only). No leftover single reminder to cancel later. Clear separation: dialog collects time + permission; AccountViewView owns native scheduling for New Activity.
-
-**Cons:** Dialog’s native path now has two behaviors (schedule vs no schedule) depending on `pushType`; needs a quick comment so future changes don’t regress.
-
-**Note:** The “edit reminder” flow already uses `skipSchedule: true` so the dialog doesn’t schedule; only the parent does. For New Activity enable, we’re doing the same idea: dialog doesn’t schedule on native, parent does.
-
-### 6.2 Option B: When turning New Activity off, also cancel the single reminder
-
-**Idea:** Assume the wrong single reminder might already exist (e.g. from before the fix, or from a different code path). When the user turns **New Activity** off, in addition to `cancelDualSchedule()`, call the service’s `cancelDailyNotification()` so the single reminder (same `reminderId` as Daily Reminder) is cancelled too.
-
-**Where:** `AccountViewView.vue`, inside the disable branch of `showNewActivityNotificationChoice()` (where we currently only call `DailyNotification.cancelDualSchedule()`).
-
-**Implementation sketch:**
-
-- On native, when user confirms “turn off New Activity”:
-  1. Call `DailyNotification.cancelDualSchedule()` (existing).
-  2. Call `NotificationService.getInstance().cancelDailyNotification()` (new) so any single reminder that was mistakenly scheduled for this flow is removed.
-
-**Pros:** Defensive: cleans up the bad schedule even if it was created in the past or by another path. Complements Option A (e.g. A prevents new wrong schedules; B cleans up existing ones).
-
-**Cons:** That single `reminderId` is shared with **Daily Reminder**. If the user has **Daily Reminder** on and **New Activity** on, then turns only **New Activity** off, we must not cancel the reminder they still want for Daily Reminder. So either:
-- Only call `cancelDailyNotification()` when we’re sure the single reminder was created for New Activity (e.g. we don’t have a separate “New Activity reminder ID”), which is hard without more state, or
-- Don’t use Option B alone as the primary fix: use Option A so we never create the single reminder for New Activity, and only add B if we decide we need a one-time cleanup or a safety net (with care not to cancel Daily Reminder’s schedule).
-
-**Recommendation:** Use Option A as the main fix. Add Option B only if the team agrees we need to cancel the single reminder on “New Activity off” and can do so without affecting Daily Reminder (e.g. by introducing a distinct reminder ID for a “New Activity legacy” reminder and only cancelling that, or by documenting that B is a one-time migration and not long-term behavior).
-
-### 6.3 Optional cleanup: Separate reminder IDs or dialog responsibilities
-
-- **Separate reminder IDs:** Today both Daily Reminder and the mistaken New Activity single reminder use `"daily_timesafari_reminder"`. If we ever want to support “both features on” and cancel only one, we’d need a second ID (e.g. one for Daily Reminder, one for New Activity). With Option A in place, New Activity no longer creates a single reminder, so we might not need a second ID unless we add a dedicated “New Activity fallback” single alarm later.
-- **Dialog responsibilities:** We could narrow the dialog’s role when used for New Activity on native to “collect time + request permission and report success,” and leave all scheduling to AccountViewView. That’s what Option A does without necessarily refactoring the rest of the dialog (e.g. web push, Daily Reminder) in the same change.
-- **Removing web-push logic for New Activity:** If the team decides to “totally remove” web-push logic that was added for New Activity, that would be a separate change (e.g. ensure New Activity on web either uses a different mechanism or is explicitly unsupported). The lay-of-the-land and this fix section focus on native; web can be scoped in a follow-up.
-
----
-
-## 7. Testing New Activity on a Real Device (iOS or Android)
-
-Use this section to verify the New Activity flow end-to-end on a physical device after implementing the fix (or to reproduce the current bug).
-
-### Prerequisites
-
-- **Build:** Native app built and installed (e.g. `npx cap sync` then build/run from Xcode or Android Studio), or a dev build on device.
-- **Identity:** User is signed in (active DID set) so `configureNativeFetcherIfReady` and the native fetcher can use a valid JWT.
-- **Endorser API URL:** New Activity prefetch uses **Account → API Server URL** (the Endorser base URL passed to `configureNativeFetcher`), not the Partner API URL. You can run these tests against **production, test, or local Endorser** (e.g. the test preset `https://test-api.endorser.ch`); use an identity, JWT, and starred plans that exist on **that** server. Changing only **Partner API** URL does not change where `plansLastUpdatedBetween` is called.
-- **Optional:** One or more starred plans so the API can return activity; with zero starred plans the notification should still show with a sensible fallback (e.g. “No updates in your starred projects”).
-
-### Enable flow
-
-1. Open **Account** (Profile).
-2. In the **Notifications** section, turn **New Activity Notification** on.
-3. In the dialog, choose a time. For quick testing, set the device clock or pick a time **2–5 minutes from now** (e.g. if it’s 14:00, choose 14:03).
-4. Tap **Turn on Daily Reminder** (or equivalent), grant notification permission when the OS prompts, and confirm the dialog closes and the toggle shows on with the chosen time.
-5. **Background the app** (home or switch to another app). The prefetch runs ~5 minutes before the chosen time; the user notification fires at the chosen time.
-
-### What to verify (after fix)
-
-- **One notification** at the chosen time, with content from the API or the fallback text (e.g. “Check your starred projects and offers for updates.”). You should **not** see a second, static “Daily Check-In” / “Time to check your TimeSafari activity” notification from the old single-reminder path.
-- **Before the fix:** You may see two notifications (one static from the mistaken single schedule, one from the dual schedule), and turning New Activity off will only stop the dual one; the static one will keep firing.
-
-### Disable flow
-
-1. On **Account**, turn **New Activity Notification** off and confirm in the “turn off” dialog.
-2. Wait until the next occurrence of the previously chosen time (or use the same “time a few minutes ahead” trick and wait). **No notification** should appear. If one still appears, the single reminder was not cancelled (current bug or Option B not applied correctly).
-
-### Device-specific notes
-
-- **Android:** This app has **exact alarm disabled** (no `SCHEDULE_EXACT_ALARM`). Notification permission must be granted; delivery may be inexact or batched by the system. If the app is killed by the OS, behavior may depend on plugin boot/recovery behavior.
-- **iOS:** Notification permission and background capabilities (e.g. background fetch) may affect prefetch. Test with app in background, not force-quit.
-- **Time zone:** The chosen time is in the device’s local time. Ensure the device date/time and time zone are correct when testing.
-
-### Optional test cases
-
-- **No starred plans:** Enable New Activity with no starred projects; confirm no crash and a sensible fallback message in the notification.
-- **JWT / API errors:** After leaving the app in background for a long time, the JWT may expire. Re-opening Account (or app) may re-run `configureNativeFetcherIfReady`; document or test whether a new notification still gets valid content or shows fallback.
-- **Daily Reminder and New Activity both on:** With the fix, turning off only New Activity should not affect the Daily Reminder notification (they use different plugin APIs; Option B must not cancel the single reminder if the user still has Daily Reminder on).
-
-### Testing: starred project with new activity (Android native fetcher)
-
-Use this to verify that when a **starred** plan has **new** activity reported by `plansLastUpdatedBetween`, the notification shows API-derived copy (not only the dual-schedule default from `dualScheduleConfig.ts`).
-
-The steps and expected notification copy below are **Android-specific**: this repo registers `TimeSafariNativeFetcher` only on Android today. Do not assume the same strings or behavior on iOS until native fetcher parity exists; see **`doc/notification-from-api-call.md`** (iOS checklist and remaining tasks).
-
-**How it works (short):** On Android, `TimeSafariNativeFetcher` POSTs to `/api/v2/report/plansLastUpdatedBetween` with `planIds` from the plugin (`updateStarredPlans`) and `afterId` from stored `last_acked_jwt_id` (or `"0"` initially). When the response `data` array is **non-empty**, the fetcher builds **one** `NotificationContent`: title **Starred Project Update** (one row) or **Starred Project Updates** (two or more rows); body uses each row’s `plan.name` when present (else **Unnamed Project**). For a single update: `[name] has been updated.` For multiple: typographic quotes around the first row’s name, then ` + N more have been updated.` (with `N` = number of additional rows). When `data` is **empty**, the fetcher returns **no** notification items (no “nothing to report” notification). (See `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java`.)
-
-**Procedure (repeatable on device)**
-
-1. Sign in on the Endorser environment you mean to test (e.g. test API URL in Account—see **Prerequisites**, Endorser API URL) so `configureNativeFetcherIfReady` can set JWT and `activeDid`.
-2. Star at least one project you can change (e.g. your own test plan on staging).
-3. Turn **New Activity Notification** on and pick a time **2–5 minutes ahead** (same quick-test pattern as above).
-4. Open **Account** once (or finish the enable flow) so `updateStarredPlans({ planIds })` runs with current `starredPlanHandleIds`.
-5. **Background the app** (home out; do not force-quit). Prefetch runs on the cron **~5 minutes before** the chosen time; the user notification fires at the chosen time.
-6. **Produce new activity the API will return:** before that prefetch window (i.e. early enough that the scheduled content fetch still sees it), make a real change to the starred plan so `plansLastUpdatedBetween` returns **new** rows after the current `afterId` (e.g. an edit or other update your backend exposes through that report). If you change the plan **after** prefetch already ran with no new rows, you may not get an API-derived notification until the next prefetch cycle (typically the next day at the same T−5 schedule, unless you reschedule).
-
-**What to verify**
-
-- **One notification** at the chosen time (no extra static “Daily Check-In” after the fix—see “What to verify (after fix)” above).
-- **Success path (API returns updates):** Title/body match **Starred Project Update(s)** and the `[name] has been updated.` / `[first name] + N more have been updated.` patterns (names from `plan.name`), not the generic `buildDualScheduleConfig` defaults (**New Activity** / **Check your starred projects and offers for updates.**), which apply when the plugin falls back—e.g. fetch failure—not when the Android fetcher successfully returns Endorser-parsed content.
-- **Contrast (cursor caught up, no new rows):** After a successful fetch that returned data, `last_acked_jwt_id` advances. Without further plan changes, a later prefetch may return an empty `data` array; the fetcher then supplies **no** Endorser-derived notification (useful to compare against the “has activity” case; the plugin may still show dual-schedule fallback text depending on configuration).
-
-**Repeatability:** Each successful fetch that returns data moves the `afterId` cursor forward. To see **Starred Project Update** copy again on subsequent tests, make **another** qualifying plan change (or accept heavier setup such as clearing app/plugin storage to reset cursor—usually unnecessary).
-
-**Debugging:** On Android, filter **logcat** for `TimeSafariNativeFetcher` (e.g. HTTP 200, `Fetched N notification(s)`) to confirm prefetch ran and how many `NotificationContent` items were built.
-
-**Note:** The in-app **New Activity** screen loads starred changes via the JS stack; the **push** path uses the native fetcher and plugin cache. Validate the notification using **background + prefetch timing**, not only by opening that screen.
-
----
-
-## 8. Plugin Repo Alignment and Attention Items
-
-Comparison with the **daily-notification-plugin** repo on gitea (`trent_larson/daily-notification-plugin`, `master` or the tag this app pins) to confirm our documentation and usage line up, and to flag anything that needs attention for the New Activity feature.
-
-### 8.1 What lines up
-
-- **API surface:** Plugin `definitions.ts` exposes `configureNativeFetcher({ apiBaseUrl, activeDid, jwtToken })`, `scheduleDualNotification(config)`, `cancelDualSchedule()`, `updateStarredPlans({ planIds })`, `scheduleDailyNotification(options)`, and `cancelDailyReminder(reminderId)`. Our app uses these as described in this doc; `buildDualScheduleConfig` produces a `DualScheduleConfiguration` that matches the plugin’s `ContentFetchConfig` / `UserNotificationConfig` / `relationship` shape (cron schedules, title/body, `callbacks: {}`, `fallbackBehavior: "show_default"`, etc.).
-- **Native fetcher:** Plugin is designed for a host-supplied JWT via `configureNativeFetcher` and a native fetcher implementation (e.g. Android `TimeSafariNativeFetcher`). Our `nativeFetcherConfig.ts` and Android `TimeSafariNativeFetcher.java` follow that model; prefetch runs in the plugin’s background workers and uses the configured credentials.
-- **Dual vs single:** The plugin clearly separates:
-  - **Single daily path:** `scheduleDailyNotification(options)` (with `id` on Android) and `cancelDailyReminder(reminderId)` (iOS uses `reminder_<reminderId>` for the static-reminder path).
-  - **Dual path:** `scheduleDualNotification(config)` and `cancelDualSchedule()`.  
-  So our analysis that “two schedules” are created when the dialog schedules the single reminder and AccountViewView schedules the dual is consistent with the plugin.
-- **Exact alarm:** The plugin’s Android implementation does **not** require exact alarm: it proceeds with scheduling using inexact/windowed alarms when exact is not granted. The plugin’s `INTEGRATION_GUIDE.md` still shows `SCHEDULE_EXACT_ALARM` in the manifest example; this app has chosen to disable exact alarm, and the plugin supports that. No doc change needed beyond what we already state in section 7.
-
-### 8.2 Attention items
-
-- **`cancelDailyReminder` signature:** In the plugin’s `definitions.ts`, `cancelDailyReminder(reminderId: string)`. The app calls it with an object: `cancelDailyReminder({ reminderId })`. On iOS the plugin uses `call.getString("reminderId")`, so the object form works. If the plugin’s TypeScript definition is ever used for strict typing, prefer updating the plugin to accept `{ reminderId: string }` or document that the bridge accepts an object with a `reminderId` key.
-- **Plugin INTEGRATION_GUIDE vs this app:** The guide describes generic polling, dual scheduling, and optional `SCHEDULE_EXACT_ALARM`. This app uses the dual-schedule + native-fetcher path only (no generic polling), and does not use exact alarm. When onboarding or debugging, treat the guide as the full plugin feature set; our flow is the “legacy dual scheduling” + native fetcher part plus `updateStarredPlans` and `configureNativeFetcher`.
-- **iOS `scheduleDailyNotification` and stable `id`:** On **Android**, the plugin uses `options.getString("id")` as the stable `scheduleId` for “one per day” semantics and cleanup. On **iOS**, the implementation in the repo was observed to build notification content with an internally generated id (e.g. `daily_<timestamp>`) and not obviously use the app-provided `id` from the call. If the app ever relies on a stable id on iOS for the single reminder (e.g. to cancel or replace only that reminder), it’s worth confirming in the plugin’s iOS code whether the call’s `id` is read and used; if not, consider requesting or contributing a change so iOS also uses the app-provided id for consistency with Android.
-- **Dual schedule and content fetch:** The plugin’s dual schedule runs the content-fetch job on its cron and then the user notification at the configured time; our config uses a 5-minute gap and `relationship.contentTimeout` / `fallbackBehavior: "show_default"`. The native fetcher is invoked by the plugin’s background layer when the content-fetch schedule fires; we don’t rely on JS `callbacks` in the config (we pass `callbacks: {}`). That matches the “native fetcher does the work” design.
-
-### 8.3 iOS `UNIMPLEMENTED` on `scheduleDualNotification` (other methods work)
-
-If iOS logs `scheduleNewActivityDualNotification failed: {"code":"UNIMPLEMENTED"}` while `configureNativeFetcher` succeeds, Capacitor is often rejecting the call in **JavaScript** because `scheduleDualNotification` is missing from `window.Capacitor.PluginHeaders` for `DailyNotification` (stale **Pods / Xcode binary** after upgrading the plugin). **Not** usually a missing Swift handler if `node_modules` already lists the method in `pluginMethods`.
-
-**Recovery:** `npx cap sync ios`, `cd ios/App && pod install`, Xcode **Clean Build Folder**, rebuild. See **`doc/plugin-feedback-ios-scheduleDualNotification.md`** (troubleshooting section).
-
-### 8.4 Summary
-
-The plugin repo aligns with how we use it for New Activity (dual schedule + native fetcher, no generic polling, exact alarm optional). The main follow-ups are: (1) clarify or align `cancelDailyReminder` argument shape in the plugin if needed for typing/tooling, and (2) confirm on iOS whether `scheduleDailyNotification` uses the app-provided `id` for stable single-reminder semantics.

doc/notification-permissions-and-rollovers.md

@@ -1,238 +0,0 @@
-# Notification Permissions & Rollover Handling
-
-**Date**: 2026-01-23  
-**Purpose**: Answers to questions about permission requests and rollover handling
-
----
-
-## Question 1: Where does the notification permission request happen?
-
-### Permission Request Flow
-
-The permission request flows through multiple layers:
-
-```
-User clicks "Turn on Daily Message"
-    ↓
-PushNotificationPermission.vue
-    ↓ (line 715)
-service.requestPermissions()
-    ↓
-NotificationService.getInstance()
-    ↓ (platform detection)
-NativeNotificationService.requestPermissions()
-    ↓ (line 53)
-DailyNotification.requestPermissions()
-    ↓
-Plugin Native Code
-    ↓
-┌─────────────────────┬─────────────────────┐
-│   iOS Platform      │   Android Platform   │
-├─────────────────────┼─────────────────────┤
-│ UNUserNotification  │ ActivityCompat       │
-│ Center.current()    │ .requestPermissions()│
-│ .requestAuthorization│                     │
-│ (options: [.alert, │ (POST_NOTIFICATIONS) │
-│  .sound, .badge])   │                     │
-└─────────────────────┴─────────────────────┘
-    ↓
-Native OS Permission Dialog
-    ↓
-User grants/denies
-    ↓
-Result returned to app
-```
-
-### Code Locations
-
-**1. UI Entry Point** (`src/components/PushNotificationPermission.vue`):
-```typescript
-// Line 715
-const granted = await service.requestPermissions();
-```
-
-**2. Service Layer** (`src/services/notifications/NativeNotificationService.ts`):
-```typescript
-// Lines 49-68
-async requestPermissions(): Promise<boolean> {
-  const result = await DailyNotification.requestPermissions();
-  return result.allPermissionsGranted;
-}
-```
-
-**3. Plugin Registration** (`src/plugins/DailyNotificationPlugin.ts`):
-```typescript
-// Line 30-36
-const DailyNotification = registerPlugin<DailyNotificationPluginType>(
-  "DailyNotification"
-);
-```
-
-**4. iOS Native Implementation** (`node_modules/@timesafari/daily-notification-plugin/ios/Plugin/DailyNotificationScheduler.swift`):
-```swift
-// Lines 113-115
-func requestPermissions() async -> Bool {
-    let granted = try await notificationCenter.requestAuthorization(
-        options: [.alert, .sound, .badge]
-    )
-    return granted
-}
-```
-
-**5. Android Native Implementation** (`node_modules/@timesafari/daily-notification-plugin/android/src/main/java/com/timesafari/dailynotification/PermissionManager.java`):
-```java
-// Line 87
-ActivityCompat.requestPermissions(
-    activity,
-    new String[]{Manifest.permission.POST_NOTIFICATIONS},
-    REQUEST_CODE
-);
-```
-
-### Platform-Specific Details
-
-#### iOS
-- **API Used**: `UNUserNotificationCenter.requestAuthorization()`
-- **Options Requested**: `.alert`, `.sound`, `.badge`
-- **Dialog**: System-native iOS permission dialog
-- **Location**: First time user enables notifications
-- **Result**: Returns `true` if granted, `false` if denied
-
-#### Android
-- **API Used**: `ActivityCompat.requestPermissions()`
-- **Permission**: `POST_NOTIFICATIONS` (Android 13+)
-- **Dialog**: System-native Android permission dialog
-- **Location**: First time user enables notifications
-- **Result**: Returns `true` if granted, `false` if denied
-- **Note**: Android 12 and below don't require runtime permission (declared in manifest)
-
-### When Permission Request Happens
-
-The permission request is triggered when:
-1. User opens the notification setup dialog (`PushNotificationPermission.vue`)
-2. User clicks "Turn on Daily Message" button
-3. App detects native platform (`isNativePlatform === true`)
-4. `turnOnNativeNotifications()` method is called
-5. `service.requestPermissions()` is called (line 715)
-
-**Important**: The permission dialog only appears **once** per app installation. After that:
-- If granted: Future calls to `requestPermissions()` return `true` immediately
-- If denied: User must manually enable in system settings
-
----
-
-## Question 2: Does the plugin handle rollovers automatically?
-
-### ✅ Yes - Rollover Handling is Automatic
-
-The plugin **automatically handles rollovers** in multiple scenarios:
-
-### 1. Initial Scheduling (Time Has Passed Today)
-
-**Location**: `ios/Plugin/DailyNotificationScheduler.swift` (lines 326-329)
-
-```swift
-// If time has passed today, schedule for tomorrow
-if scheduledDate <= now {
-    scheduledDate = calendar.date(byAdding: .day, value: 1, to: scheduledDate) ?? scheduledDate
-}
-```
-
-**Behavior**: 
-- If user schedules a notification for 9:00 AM but it's already 10:00 AM today
-- Plugin automatically schedules it for 9:00 AM **tomorrow**
-- No manual intervention needed
-
-### 2. Daily Rollover (After Notification Fires)
-
-**Location**: `ios/Plugin/DailyNotificationScheduler.swift` (lines 437-609)
-
-The plugin has a `scheduleNextNotification()` function that:
-- Automatically schedules the next day's notification after current one fires
-- Handles 24-hour rollovers with DST (Daylight Saving Time) awareness
-- Prevents duplicate rollovers with state tracking
-
-**Key Function**: `calculateNextScheduledTime()` (lines 397-435)
-```swift
-// Add 24 hours (handles DST transitions automatically)
-guard let nextDate = calendar.date(byAdding: .hour, value: 24, to: currentDate) else {
-    // Fallback to simple 24-hour addition
-    return currentScheduledTime + (24 * 60 * 60 * 1000)
-}
-```
-
-**Features**:
-- ✅ DST-safe: Uses Calendar API to handle daylight saving transitions
-- ✅ Automatic: No manual scheduling needed
-- ✅ Persistent: Survives app restarts and device reboots
-- ✅ Duplicate prevention: Tracks rollover state to prevent duplicates
-
-### 3. Rollover State Tracking
-
-**Location**: `ios/Plugin/DailyNotificationStorage.swift` (lines 161-195)
-
-The plugin tracks rollover state to prevent duplicate scheduling:
-
-```swift
-// Check if rollover was processed recently (< 1 hour ago)
-if let lastTime = lastRolloverTime,
-   (currentTime - lastTime) < (60 * 60 * 1000) {
-    // Skip - already processed
-    return false
-}
-```
-
-**Purpose**: Prevents multiple rollover attempts if notification fires multiple times
-
-### 4. Android Rollover Handling
-
-Android implementation also handles rollovers:
-- Uses `AlarmManager` with `setRepeating()` or schedules next alarm after current fires
-- Handles timezone changes and DST transitions
-- Persists across device reboots via `BootReceiver`
-
-### Rollover Scenarios Handled
-
-| Scenario | Handled? | How |
-|----------|----------|-----|
-| Time passed today | ✅ Yes | Schedules for tomorrow automatically |
-| Daily rollover | ✅ Yes | Schedules next day after notification fires |
-| DST transitions | ✅ Yes | Uses Calendar API for DST-aware calculations |
-| Device reboot | ✅ Yes | BootReceiver restores schedules |
-| App restart | ✅ Yes | Schedules persist in database |
-| Duplicate prevention | ✅ Yes | State tracking prevents duplicate rollovers |
-
-### Verification
-
-You can verify rollover handling by:
-
-1. **Check iOS logs** for rollover messages:
-   ```
-   DNP-ROLLOVER: START id=... current_time=... scheduled_time=...
-   DNP-ROLLOVER: CALC_NEXT current=... next=... diff_hours=24.00
-   ```
-
-2. **Test scenario**: Schedule notification for a time that's already passed today
-   - Expected: Notification scheduled for tomorrow at same time
-
-3. **Test scenario**: Wait for notification to fire
-   - Expected: Next day's notification automatically scheduled
-
-### Summary
-
-✅ **Permission Request**: Happens in native plugin code via platform-specific APIs:
-- iOS: `UNUserNotificationCenter.requestAuthorization()`
-- Android: `ActivityCompat.requestPermissions()`
-
-✅ **Rollover Handling**: Fully automatic:
-- Initial scheduling: If time passed, schedules for tomorrow
-- Daily rollover: Automatically schedules next day after notification fires
-- DST handling: Calendar-aware calculations
-- Duplicate prevention: State tracking prevents issues
-- Persistence: Survives app restarts and device reboots
-
-**No manual intervention needed** - the plugin handles all rollover scenarios automatically!
-
----
-
-**Last Updated**: 2026-01-23

doc/notification-system-overview.md

@@ -1,378 +0,0 @@
-# Notification System Overview
-
-**Date**: 2026-01-23  
-**Purpose**: Understanding notification architecture and implementation guide for daily-notification-plugin
-
----
-
-## Executive Summary
-
-Your app has **two separate notification systems** that coexist:
-
-1. **Web Push Notifications** (Web/PWA platforms)
-   - Uses service workers, VAPID keys, and a push server
-   - Requires the "Notification Push Server" setting
-   - Server-based delivery
-
-2. **Native Notifications** (iOS/Android via DailyNotificationPlugin)
-   - Uses native OS notification APIs
-   - On-device scheduling (no server needed)
-   - The "Notification Push Server" setting is **NOT used** for native
-
-The system automatically selects the correct implementation based on platform using `Capacitor.isNativePlatform()`.
-
----
-
-## Notification Push Server Setting
-
-### Location
-- **File**: `src/views/AccountViewView.vue` (lines 506-549)
-- **UI Section**: Advanced Settings → "Notification Push Server"
-- **Database Field**: `settings.webPushServer`
-
-### Purpose
-The "Notification Push Server" setting **ONLY applies to Web Push notifications** (web/PWA platforms). It configures:
-
-1. **VAPID Key Retrieval**: The server URL used to fetch VAPID (Voluntary Application Server Identification) keys
-2. **Subscription Endpoint**: Where push subscriptions are sent
-3. **Push Message Delivery**: The server that sends push messages to browsers
-
-### How It Works (Web Push Flow)
-
-```
-User enables notification
-    ↓
-PushNotificationPermission.vue opens
-    ↓
-Fetches VAPID key from: {webPushServer}/web-push/vapid
-    ↓
-Subscribes to browser push service
-    ↓
-Sends subscription + time + message to: {webPushServer}/web-push/subscribe
-    ↓
-Server stores subscription and schedules push messages
-    ↓
-Server sends push messages at scheduled time via browser push service
-```
-
-### Key Code Locations
-
-**AccountViewView.vue** (lines 1473-1479):
-```typescript
-async onClickSavePushServer(): Promise<void> {
-  await this.$saveSettings({
-    webPushServer: this.webPushServerInput,
-  });
-  this.webPushServer = this.webPushServerInput;
-  this.notify.warning(ACCOUNT_VIEW_CONSTANTS.INFO.RELOAD_VAPID);
-}
-```
-
-**PushNotificationPermission.vue** (lines 177-221):
-- Retrieves `webPushServer` from settings
-- Fetches VAPID key from `{webPushServer}/web-push/vapid`
-- Uses VAPID key to subscribe to push notifications
-
-**PushNotificationPermission.vue** (lines 556-575):
-- Sends subscription to `/web-push/subscribe` endpoint (relative URL, handled by service worker)
-
-### Important Notes
-
-- ⚠️ **This setting is NOT used for native iOS/Android notifications**
-- The setting defaults to `DEFAULT_PUSH_SERVER` if not configured
-- Changing the server requires reloading VAPID keys (hence the warning message)
-- Local development (`http://localhost`) skips VAPID key retrieval
-
----
-
-## Daily Notification Plugin Integration
-
-### Current Status
-
-✅ **Infrastructure Complete**:
-- Plugin registered (`src/plugins/DailyNotificationPlugin.ts`)
-- Service abstraction layer created (`src/services/notifications/`)
-- Platform detection working
-- Native implementation ready (`NativeNotificationService.ts`)
-
-🔄 **UI Integration Needed**:
-- `PushNotificationPermission.vue` still uses web push logic
-- AccountViewView notification toggles need platform detection
-- Settings storage needs to handle both systems
-
-### Architecture
-
-```
-NotificationService.getInstance()
-    ↓
-Platform Detection (Capacitor.isNativePlatform())
-    ↓
-┌─────────────────────┬─────────────────────┐
-│   Native Platform   │    Web Platform      │
-│   (iOS/Android)     │    (Web/PWA)         │
-├─────────────────────┼─────────────────────┤
-│ NativeNotification  │ WebPushNotification  │
-│ Service             │ Service              │
-│                     │                      │
-│ Uses:               │ Uses:                │
-│ - DailyNotification │ - Service Workers   │
-│   Plugin            │ - VAPID Keys         │
-│ - Native OS APIs    │ - Push Server        │
-│ - On-device alarms  │ - Server scheduling  │
-└─────────────────────┴─────────────────────┘
-```
-
-### Key Differences
-
-| Feature | Native (Plugin) | Web Push |
-|---------|----------------|----------|
-| **Server Required** | ❌ No | ✅ Yes (Notification Push Server) |
-| **Scheduling** | On-device | Server-side |
-| **Offline Delivery** | ✅ Yes | ❌ No (requires network) |
-| **Background Support** | ✅ Full | ⚠️ Limited (browser-dependent) |
-| **Permission Model** | OS-level | Browser-level |
-| **Settings Storage** | Local only | Local + server subscription |
-
----
-
-## Implementation Recommendations
-
-### 1. Update PushNotificationPermission Component
-
-**Current State**: Only handles web push
-
-**Recommended Changes**:
-
-```typescript
-// In PushNotificationPermission.vue
-import { NotificationService } from '@/services/notifications';
-import { Capacitor } from '@capacitor/core';
-
-async open(pushType: string, callback?: ...) {
-  const isNative = Capacitor.isNativePlatform();
-  
-  if (isNative) {
-    // Use native notification service
-    const service = NotificationService.getInstance();
-    const granted = await service.requestPermissions();
-    
-    if (granted) {
-      // Show time picker UI
-      // Then schedule via service.scheduleDailyNotification()
-    }
-  } else {
-    // Existing web push logic
-    // ... current implementation ...
-  }
-}
-```
-
-### 2. Update AccountViewView Notification Toggles
-
-**Current State**: Always uses `PushNotificationPermission` component (web push)
-
-**Recommended Changes**:
-
-```typescript
-// In AccountViewView.vue
-import { NotificationService } from '@/services/notifications';
-import { Capacitor } from '@capacitor/core';
-
-async showNewActivityNotificationChoice(): Promise<void> {
-  const isNative = Capacitor.isNativePlatform();
-  
-  if (isNative) {
-    // Use native service directly
-    const service = NotificationService.getInstance();
-    // Show time picker, then schedule
-  } else {
-    // Use existing PushNotificationPermission component
-    (this.$refs.pushNotificationPermission as PushNotificationPermission)
-      .open(DAILY_CHECK_TITLE, ...);
-  }
-}
-```
-
-### 3. Settings Storage Strategy
-
-**Current Settings Fields** (from `src/db/tables/settings.ts`):
-- `notifyingNewActivityTime` - Time string for daily check
-- `notifyingReminderTime` - Time string for reminder
-- `notifyingReminderMessage` - Reminder message text
-- `webPushServer` - Push server URL (web only)
-
-**Recommendation**: These settings work for both systems:
-- ✅ `notifyingNewActivityTime` - Works for both (native stores locally, web sends to server)
-- ✅ `notifyingReminderTime` - Works for both
-- ✅ `notifyingReminderMessage` - Works for both
-- ⚠️ `webPushServer` - Only used for web push (hide on native platforms)
-
-### 4. Platform-Aware UI
-
-**Recommendations**:
-
-1. **Hide "Notification Push Server" setting on native platforms**:
-   ```vue
-   <h2 v-if="!isNativePlatform" class="text-slate-500 text-sm font-bold mb-2">
-     Notification Push Server
-   </h2>
-   ```
-
-2. **Update help text** to explain platform differences
-
-3. **Show different messaging** based on platform:
-   - Native: "Notifications are scheduled on your device"
-   - Web: "Notifications are sent via push server"
-
----
-
-## Notification Types
-
-Your app supports two notification types:
-
-### 1. Daily Check (`DAILY_CHECK_TITLE`)
-- **Purpose**: Notify user of new activity/updates
-- **Message**: Auto-generated by server (web) or app (native)
-- **Settings Field**: `notifyingNewActivityTime`
-
-### 2. Direct Push (`DIRECT_PUSH_TITLE`)
-- **Purpose**: Daily reminder with custom message
-- **Message**: User-provided (max 100 characters)
-- **Settings Fields**: `notifyingReminderTime`, `notifyingReminderMessage`
-
-Both types can be enabled simultaneously.
-
----
-
-## Code Flow Examples
-
-### Native Notification Flow (Recommended Implementation)
-
-```typescript
-// 1. Get service instance
-const service = NotificationService.getInstance();
-
-// 2. Request permissions
-const granted = await service.requestPermissions();
-if (!granted) {
-  // Show error, guide to settings
-  return;
-}
-
-// 3. Schedule notification
-await service.scheduleDailyNotification({
-  time: '09:00', // HH:mm format (24-hour)
-  title: 'Daily Check-In',
-  body: 'Time to check your TimeSafari activity',
-  priority: 'normal'
-});
-
-// 4. Save to settings
-await this.$saveSettings({
-  notifyingNewActivityTime: '09:00'
-});
-
-// 5. Check status
-const status = await service.getStatus();
-console.log('Enabled:', status.enabled);
-console.log('Time:', status.scheduledTime);
-```
-
-### Web Push Flow (Current Implementation)
-
-```typescript
-// 1. Open PushNotificationPermission component
-(this.$refs.pushNotificationPermission as PushNotificationPermission)
-  .open(DAILY_CHECK_TITLE, async (success, timeText) => {
-    if (success) {
-      // Component handles:
-      // - VAPID key retrieval from webPushServer
-      // - Service worker subscription
-      // - Sending subscription to server
-      
-      // Just save the time
-      await this.$saveSettings({
-        notifyingNewActivityTime: timeText
-      });
-    }
-  });
-```
-
----
-
-## Testing Checklist
-
-### Native (iOS/Android)
-- [ ] Request permissions works
-- [ ] Notification appears at scheduled time
-- [ ] Notification survives app close
-- [ ] Notification survives device reboot
-- [ ] Both notification types can be enabled
-- [ ] Cancellation works correctly
-
-### Web Push
-- [ ] VAPID key retrieval works
-- [ ] Service worker subscription works
-- [ ] Subscription sent to server
-- [ ] Push messages received at scheduled time
-- [ ] Works with different push server URLs
-
-### Platform Detection
-- [ ] Correct service selected on iOS
-- [ ] Correct service selected on Android
-- [ ] Correct service selected on web
-- [ ] Settings UI shows/hides appropriately
-
----
-
-## Key Files Reference
-
-### Core Notification Services
-- `src/services/notifications/NotificationService.ts` - Factory/selector
-- `src/services/notifications/NativeNotificationService.ts` - Native implementation
-- `src/services/notifications/WebPushNotificationService.ts` - Web implementation (stub)
-
-### UI Components
-- `src/components/PushNotificationPermission.vue` - Web push UI (needs update)
-- `src/views/AccountViewView.vue` - Settings UI (lines 506-549 for push server)
-
-### Settings & Constants
-- `src/db/tables/settings.ts` - Settings schema
-- `src/constants/app.ts` - `DEFAULT_PUSH_SERVER` constant
-- `src/libs/util.ts` - `DAILY_CHECK_TITLE`, `DIRECT_PUSH_TITLE`
-
-### Plugin
-- `src/plugins/DailyNotificationPlugin.ts` - Plugin registration
-
----
-
-## Next Steps
-
-1. **Update `PushNotificationPermission.vue`** to detect platform and use appropriate service
-2. **Update `AccountViewView.vue`** notification toggles to use platform detection
-3. **Hide "Notification Push Server" setting** on native platforms
-4. **Test on real devices** (iOS and Android)
-5. **Update documentation** with platform-specific instructions
-
----
-
-## Questions & Answers
-
-**Q: Do I need to configure the Notification Push Server for native apps?**  
-A: No. The setting is only for web push. Native notifications are scheduled on-device.
-
-**Q: Can both notification systems be active at the same time?**  
-A: No, they're mutually exclusive per platform. The app automatically selects the correct one.
-
-**Q: How do I test native notifications?**  
-A: Use `NotificationService.getInstance()` and test on a real device (simulators have limitations).
-
-**Q: What happens if I change the push server URL?**  
-A: Only affects web push. Users need to re-subscribe to push notifications with the new server.
-
-**Q: Can I use the same settings fields for both systems?**  
-A: Yes! The time and message fields work for both. Only `webPushServer` is web-specific.
-
----
-
-**Last Updated**: 2026-01-23

doc/notification-system.md

@@ -0,0 +1,231 @@
+# TimeSafari — Native-First Notification System
+
+**Status:** Ready for implementation  
+**Date:** 2025-09-07  
+**Author:** Matthew Raymer
+
+---
+
+## Executive Summary
+
+Ship a **single, Native-First** notification system: OS-scheduled **background prefetch at T–lead** + **pre-armed** local notifications. Web-push is retired.
+
+### What we deliver
+
+- **Closed-app delivery:** Pre-armed locals fire even if the app is closed.
+- **Freshness:** One prefetch attempt per slot at **T–lead**; ETag/TTL controls; skip when stale.
+- **Android precision:** Exact alarms with permission; windowed fallback (±10m) otherwise.
+- **Resilience:** Re-arm after reboot/time-change (Android receivers; iOS on next wake/silent push).
+- **Cross-platform:** Same TS API (iOS/Android/Electron). Electron is best-effort while running.
+
+### Success signals
+
+- High delivery reliability, minute-precision on Android with permission.
+- Prefetch budget hit rate at **T–lead**; zero stale deliveries beyond TTL.
+
+---
+
+## Strategic Plan
+
+### Goal
+
+Deliver 1..M daily notifications with **OS background prefetch at T–lead** and **rolling-window safety** so messages display with fresh content even when the app is closed.
+
+### Tenets
+
+- **Reliability first:** OS delivers once scheduled; no JS at delivery time.
+- **Freshness with guardrails:** Prefetch at **T–lead**; enforce **TTL-at-fire**; ETag-aware.
+- **Single system:** One TS API; native adapters swap under the hood.
+- **Platform honesty:** Android exactness via permission; iOS best-effort budget.
+
+### Architecture (high level)
+
+App (Vue/TS) → Orchestrator (policy) → Native Adapters:
+
+- **SchedulerNative** — AlarmManager (Android) / UNUserNotificationCenter (iOS)  
+- **BackgroundPrefetchNative** — WorkManager (Android) / BGTaskScheduler (+ silent push) (iOS)  
+- **DataStore** — SQLite
+
+**Storage (single shared DB):** The app and the native plugin will use **the same SQLite database file**. The app owns schema/migrations; the plugin opens the same file with WAL enabled and performs short, serialized writes. This keeps one source of truth for payloads, delivery logs, and config.
+
+### SQLite Ownership & Concurrency
+
+* **One DB file:** The plugin opens the **same path** the app uses (no second DB).
+* **Migrations owned by app:** The app executes schema migrations and bumps `PRAGMA user_version`. The plugin **never** migrates; it **asserts** the expected version.
+* **WAL mode:** Open DB with `journal_mode=WAL`, `synchronous=NORMAL`, `busy_timeout=5000`, `foreign_keys=ON`. WAL allows foreground reads while a background job commits quickly.
+* **Single-writer discipline:** Background jobs write in **short transactions** (UPSERT per slot), then return.
+* **Encryption (optional):** If using SQLCipher, the **same key** is used by both app and plugin. Do not mix encrypted and unencrypted openings.
+
+### Scheduling & T–lead
+
+- **Arm** a rolling window (today + tomorrow within iOS cap).  
+- **Attempt** a single **online-first** fetch per slot at **T–lead = T − prefetchLeadMinutes**.  
+- If prefetch is skipped, the armed local **still fires** using cached content.
+
+### Policies
+
+- **TTL-at-fire:** If (T − fetchedAt) > `ttlSeconds` → **skip** arming.  
+- **Android exactness:** Request `SCHEDULE_EXACT_ALARM`; fallback **±10m** window.  
+- **Reboot/time change:** Android receivers re-arm next 24h; iOS on next wake/silent push.  
+- **No delivery-time mutation:** iOS locals cannot be mutated by NSE; render before scheduling.
+
+---
+
+## Implementation Guide
+
+### 1) Interfaces (TS stable)
+
+- **SchedulerNative**: `scheduleExact({slotId, whenMs, title, body, extra})`, `scheduleWindow(..., windowLenMs)`, `cancelBySlot`, `rescheduleAll`, `capabilities()`
+- **BackgroundPrefetchNative**: `schedulePrefetch(slotId, atMs)`, `cancelPrefetch(slotId)`
+- **DataStore**: SQLite adapters (notif_contents, notif_deliveries, notif_config)
+- **Public API**: `configure`, `requestPermissions`, `runFullPipelineNow`, `reschedule`, `getState`
+
+### DB Path & Adapter Configuration
+
+* **Configure option:** `dbPath: string` (absolute path or platform alias) is passed from JS to the plugin during `configure()`.
+* **Shared tables:**
+
+  * `notif_contents(slot_id, payload_json, fetched_at, etag, …)`
+  * `notif_deliveries(slot_id, fire_at, delivered_at, status, error_code, …)`
+  * `notif_config(k, v)`
+* **Open settings:**
+
+  * `journal_mode=WAL`
+  * `synchronous=NORMAL`
+  * `busy_timeout=5000`
+  * `foreign_keys=ON`
+
+**Type (TS) extension**
+
+```ts
+export type ConfigureOptions = {
+  // …existing fields…
+  dbPath: string;                 // shared DB file the plugin will open
+  storage: 'shared';              // canonical value; plugin-owned DB is not used
+};
+```
+
+**Plugin side (pseudo)**
+
+```kotlin
+// Android open
+val db = SQLiteDatabase.openDatabase(dbPath, null, SQLiteDatabase.OPEN_READWRITE)
+db.execSQL("PRAGMA journal_mode=WAL")
+db.execSQL("PRAGMA synchronous=NORMAL")
+db.execSQL("PRAGMA foreign_keys=ON")
+db.execSQL("PRAGMA busy_timeout=5000")
+// Verify schema version
+val uv = rawQuery("PRAGMA user_version").use { it.moveToFirst(); it.getInt(0) }
+require(uv >= MIN_EXPECTED_VERSION) { "Schema version too old" }
+```
+
+```swift
+// iOS open (FMDB / SQLite3)
+// Set WAL via PRAGMA after open; check user_version the same way.
+```
+
+### 2) Templating & Arming
+
+- Render `title/body` **before** scheduling; pass via **SchedulerNative**.
+- Route all arming through **SchedulerNative** to centralize Android exact/window semantics.
+
+### 3) T–lead (single attempt)
+
+**T–lead governs prefetch, not arming.** We **arm** one-shot locals as part of the rolling window so closed-app delivery is guaranteed. At **T–lead = T − prefetchLeadMinutes**, the **native background job** attempts **one** 12s ETag-aware fetch. If fresh content arrives and will not violate **TTL-at-fire**, we (re)arm the upcoming slot; if the OS skips the wake, the pre-armed local still fires with cached content.
+
+- Compute T–lead = `whenMs - prefetchLeadMinutes*60_000`.
+- `BackgroundPrefetchNative.schedulePrefetch(slotId, atMs=T–lead)`.
+- On wake: **ETag** fetch (timeout **12s**), persist, optionally cancel & re-arm if within TTL.
+- Never fetch at delivery time.
+
+### 4) TTL-at-fire
+
+**TTL-at-fire:** Before arming for time **T**, compute `T − fetchedAt`. If that exceeds `ttlSeconds`, **do not arm** (skip). This prevents posting stale notifications when the app has been closed for a long time.
+
+`if (whenMs - fetchedAt) > ttlSeconds*1000 → skip`
+
+### 5) Android specifics
+
+- Request `SCHEDULE_EXACT_ALARM`; deep-link if denied; fallback to `setWindow(start,len)` (±10m).
+- Receivers: `BOOT_COMPLETED`, `TIMEZONE_CHANGED`, `TIME_SET` → recompute & re-arm for next 24h and schedule T–lead prefetch.
+
+### 6) iOS specifics
+
+- `BGTaskScheduler` for T–lead prefetch (best-effort). Optional silent push nudge.
+- Locals: `UNCalendarNotificationTrigger` (one-shots); no NSE mutation for locals.
+
+### 7) Network & Timeouts
+
+- Content fetch: **12s** timeout; single attempt at T–lead; ETag/304 respected.
+- ACK/Error: **8s** timeout, fire-and-forget.
+
+### 8) Electron
+
+- Notifications while app is running; recommend **Start-on-Login**. No true background scheduling when fully closed.
+
+### 9) Telemetry
+
+- Record `scheduled|shown|error`; ACK deliveries (8s timeout); include slot/times/TZ/app version.
+
+---
+
+## Capability Matrix
+
+| Capability | Android (Native) | iOS (Native) | Electron | Web |
+|---|---|---|---|---|
+| Multi-daily locals (closed app) | ✅ | ✅ | ✅ (app running) | — |
+| Prefetch at T–lead (app closed) | ✅ WorkManager | ⚠️ BGTask (best-effort) | ✅ (app running) | — |
+| Re-arm after reboot/time-change | ✅ Receivers | ⚠️ On next wake/silent push | ✅ Start-on-Login | — |
+| Minute-precision alarms | ✅ with exact permission | ❌ not guaranteed | ✅ timer best-effort | — |
+| Delivery-time mutation for locals | ❌ | ❌ | — | — |
+| ETag/TTL enforcement | ✅ | ✅ | ✅ | — |
+| Rolling-window safety | ✅ | ✅ | ✅ | — |
+
+---
+
+## Acceptance Criteria
+
+### Core
+
+- **Closed-app delivery:** Armed locals fire at T with last rendered content. No delivery-time network.
+- **T–lead prefetch:** Single background attempt at **T–lead**; if skipped, delivery still occurs from cache.
+- **TTL-at-fire:** No armed local violates TTL at T.
+
+### Android
+
+- **Exact permission path:** With `SCHEDULE_EXACT_ALARM` → within ±1m; else **±10m** window.
+- **Reboot recovery:** After reboot, receivers re-arm next 24h and schedule T–lead prefetch.
+- **TZ/DST change:** Recompute & re-arm; future slots align to new wall-clock.
+
+### iOS
+
+- **BGTask budget respected:** Prefetch often runs but may be skipped; delivery still occurs via rolling window.
+- **Force-quit caveat:** No background execution after user terminate; delivery still occurs if pre-armed.
+
+### Electron
+
+- **Running-app rule:** Delivery only while app runs; with Start-on-Login, after reboot the orchestrator re-arms and subsequent slots deliver.
+
+### Network
+
+- Content fetch timeout **12s**; ACK/Error **8s**; no retries inside lead; ETag honored.
+
+### Observability
+
+- Log/telemetry for `scheduled|shown|error`; ACK payload includes slot, times, device TZ, app version.
+
+### DB Sharing
+
+* **Shared DB visibility:** A background prefetch writes `notif_contents`; the foreground UI **immediately** reads the same row.
+* **WAL overlap:** With the app reading while the plugin commits, no user-visible blocking occurs.
+* **Version safety:** If `user_version` is behind, the plugin emits an error and does not write (protects against partial installs).
+
+---
+
+## Web-Push Cleanup
+
+Web-push functionality has been retired due to unreliability. All web-push related code paths and documentation sections should be removed or marked as deprecated. See `web-push-cleanup-guide.md` for detailed cleanup steps.
+
+---
+
+_This document consolidates the Native-First notification system strategy, implementation details, capabilities, and acceptance criteria into a single comprehensive reference._

doc/plan-background-jwt-pool-and-expiry.md

@@ -1,203 +0,0 @@
-# Plan: Background New Activity JWT — extended expiry + token pool
-
-**Date:** 2026-03-27 14:29 PST  
-**Status:** Draft for implementation  
-**Audience:** TimeSafari / crowd-funder developers  
-**Related:** `doc/endorser-jwt-background-prefetch-options.md`, `android/.../TimeSafariNativeFetcher.java`, `src/services/notifications/nativeFetcherConfig.ts`, `src/libs/crypto/index.ts`
-
----
-
-## 1. Problem statement
-
-Background prefetch for New Activity calls Endorser with a Bearer JWT configured via `configureNativeFetcher`. The token previously came from `getHeaders()` → `accessToken()`, which used **`exp` ≈ 60 seconds** (`src/libs/crypto/index.ts`). Prefetch runs **minutes later** in WorkManager **without JavaScript**, so the JWT can be **expired** before the POST (`JWT_VERIFY_FAILED`).
-
-**Goals:**
-
-1. Use JWTs whose **`exp`** covers the gap between **last app-side configure** and **prefetch** (and ideally days without opening the app).
-2. Optionally support a **pool** of distinct JWT strings so Endorser can enforce **duplicate-JWT** / **one-time-use** rules without breaking daily prefetch. **Pool size** should follow **`expiryDays + buffer`** (one distinct token per day over the JWT lifetime, plus headroom for retries / edge cases); **implementation uses `BACKGROUND_JWT_POOL_SIZE = 100`** until policy changes.
-3. Keep pool size and expiry policy **easy to change** (constants / remote config later).
-
----
-
-## 2. Guiding principles
-
-| Principle | Implication |
-|-----------|-------------|
-| **Background has no JS** | Token selection and HTTP must run in **native** (or plugin) code using **persisted** data. |
-| **Single source of truth for signing** | Continue using **`createEndorserJwtForDid`** (same keys as today); do not fork crypto in Java/Kotlin. |
-| **Configurable pool size** | One constant `BACKGROUND_JWT_POOL_SIZE`; **currently 100**. Size should satisfy **`≥ expiryDays + buffer`** (see below). |
-| **Phased delivery** | Ship **extended expiry** first; add **pool** when server duplicate rules require it or in the same release if coordinated. |
-
-### 2.1 Pool size rationale (`expiryDays + buffer`)
-
-For **one New Activity prefetch per day**, each day should use a **distinct** JWT string if the server rejects reuse. Over the JWT lifetime (aligned with **`exp`**), you need at least **one token per day** the pool might be used without regeneration.
-
-**Rule of thumb:**
-
-```text
-BACKGROUND_JWT_POOL_SIZE ≥ ceil(BACKGROUND_JWT_EXPIRY_DAYS) + BACKGROUND_JWT_POOL_BUFFER
-```
-
-- **`BACKGROUND_JWT_EXPIRY_DAYS`** — human-facing match to `exp` (e.g. **90**); convert to `BACKGROUND_JWT_EXPIRY_SECONDS` for the payload.
-- **`BACKGROUND_JWT_POOL_BUFFER`** — extra slots for **same-day retries**, manual tests, or stricter duplicate rules (e.g. **10**).
-
-**Example:** 90‑day `exp` + buffer 10 ⇒ **minimum 100** logical slots. **This plan keeps `BACKGROUND_JWT_POOL_SIZE = 100`** as the shipped default so it matches that example; if `expiryDays` or buffer change later, **bump the constant** so the inequality still holds.
-
----
-
-## 3. Phases
-
-### Phase A — Extended expiry only (minimum viable)
-
-**Scope**
-
-- Introduce a dedicated mint path for **background / native fetcher** use (name TBD, e.g. `accessTokenForBackgroundNotifications(did)`), producing **one** JWT per configure call with:
-  - `iss`: DID (unchanged)
-  - `iat`: now
-  - `exp`: now + **`BACKGROUND_JWT_EXPIRY_SECONDS`** (derived from **`BACKGROUND_JWT_EXPIRY_DAYS`**; see §2.1 / Phase B constants — **confirm** with Endorser policy)
-  - Optional: `jti` or nonce for uniqueness if needed for logging/debug
-
-- **`configureNativeFetcherIfReady`** should pass this token (or keep using a thin wrapper) instead of reusing the **60s** `accessToken()` when configuring native fetcher **only** — **do not** change interactive `getHeaders()` / passkey caching behavior for normal API calls unless product asks for it.
-
-**Files (likely)**
-
-- `src/libs/crypto/index.ts` — new function or parameters; keep `accessToken()` default at 60s for existing callers.
-- `src/services/notifications/nativeFetcherConfig.ts` — obtain background JWT via the new mint path, not `getHeaders()`’s generic path, **or** add a dedicated branch that calls the new mint after resolving `did`.
-
-**Native**
-
-- **`TimeSafariNativeFetcher`**: still one `jwtToken` field; no pool yet. Ensure `configure()` is called whenever TS refreshes (startup, resume, Account — already partially covered).
-
-**Exit criteria**
-
-- Logcat: prefetch POST returns **200** (or non-expired 4xx) when user has not opened the app for several **minutes** after configure.
-- Endorser accepts **`exp`** far enough in the future (coordinate TTL policy).
-
----
-
-### Phase B — Token pool (size 100; driven by `expiryDays + buffer`)
-
-**Why**
-
-- Endorser may **reject duplicate JWT strings** (same bearer used twice). One long-lived token could fail on **day 2** if the server marks each JWT as consumed.
-- A **pool** of **N** distinct JWTs (different payload, e.g. unique `jti` per token) gives **N** independent strings with the same long **`exp`**. **N** should follow **§2.1** (`expiryDays + buffer`); **100** is the initial **`BACKGROUND_JWT_POOL_SIZE`** (satisfies e.g. 90 + 10).
-
-**Scope**
-
-1. **Constants** (single place, e.g. `src/constants/backgroundJwt.ts` or next to native fetcher config):
-
-   ```text
-   BACKGROUND_JWT_EXPIRY_DAYS = 90              // align with Endorser; drives exp
-   BACKGROUND_JWT_EXPIRY_SECONDS = 90 * 24 * 60 * 60  // derived
-   BACKGROUND_JWT_POOL_BUFFER = 10            // retries / headroom; tune with server team
-   BACKGROUND_JWT_POOL_SIZE = 100               // must be >= expiryDays + buffer; adjust if policy changes
-   ```
-
-2. **Mint in TS** (uses `createEndorserJwtForDid`):
-
-   - Loop `i = 0 .. POOL_SIZE - 1`
-   - Payload: `{ iss, iat, exp, jti: `${did}#bg#${i}` or uuid }` — **confirm** `jti` format with Endorser if required.
-
-3. **Persistence** — native code must read the pool **without JS**:
-
-   - **Option B1 (preferred):** Implement in **`@timesafari/daily-notification-plugin`** (not in the app): extend **`configureNativeFetcher`** to accept an optional JWT pool, persist it for native read. **Handoff spec:** `doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md` — copy or reference that file in the plugin repo PR.
-   - **Option B2 (app-only, no plugin release):** Write JSON to **Capacitor Preferences** or **encrypted storage** from TS; **TimeSafariNativeFetcher** reads the same store on Android (requires knowing Capacitor’s Android `SharedPreferences` name/key convention or a tiny **bridge** in `MainActivity`). Use only if plugin work is deferred.
-
-4. **Selection policy in `TimeSafariNativeFetcher`** (before each POST):
-
-   - **By calendar day:** `index = (epochDay + offset) % POOL_SIZE` (stable per day).
-   - Or **sequential:** persist `lastUsedIndex` in prefs and increment (wrap). **Decision:** document chosen policy; day-based is easier to reason about for “one token per day.”
-
-5. **configureNativeFetcherIfReady** (and any “reset notifications on startup” hook):
-
-   - Regenerate full pool when user opens app (per product decision), then call configure with pool + **current** `apiBaseUrl` / `did`.
-
-6. **iOS:** When iOS native fetcher exists, mirror Android behavior.
-
-**Exit criteria**
-
-- Prefetch succeeds on **consecutive days** with duplicate-JWT enforcement enabled on a **staging** Endorser.
-- Pool **refreshes** on startup without breaking dual schedule.
-
----
-
-## 4. Detailed tasks (checklist)
-
-### Crypto & TypeScript
-
-- [ ] Add `BACKGROUND_JWT_EXPIRY_DAYS`, `BACKGROUND_JWT_EXPIRY_SECONDS`, `BACKGROUND_JWT_POOL_BUFFER`, and `BACKGROUND_JWT_POOL_SIZE` (exported constants), with a **comment** that `POOL_SIZE >= expiryDays + buffer` (see §2.1).
-- [ ] Implement `mintBackgroundJwtPool(did: string): Promise<string[]>` (or split single + pool).
-- [ ] Ensure each JWT has **unique** `jti` (or equivalent) for duplicate detection.
-- [ ] **Do not** break existing `accessToken()` 60s behavior for unrelated features.
-- [ ] Wire `configureNativeFetcherIfReady` to pass **single extended token** (Phase A) then **pool** (Phase B).
-- [ ] On **logout / identity clear**, clear persisted pool and call plugin clear if needed.
-
-### Android
-
-- [ ] **Phase A:** No structural change if `configure()` still receives one string; verify non-null `jwtToken` after configure.
-- [ ] **Phase B:** Parse pool from persisted JSON; implement `selectTokenForRequest()`; use selected token in `Authorization` header instead of sole `jwtToken` field (keep `configure` for `apiBaseUrl` / `did`).
-- [ ] Unit or instrumentation tests optional: selection index deterministic.
-
-### Plugin (Option B1 — **daily-notification-plugin** repo)
-
-- [ ] Follow **`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`** (API shape, Android/iOS, versioning).
-- [ ] Release new plugin version; bump dependency in this app.
-
-### Product & server
-
-- [ ] Endorser: confirm **max `exp`**, **duplicate JWT** semantics, recommended **`jti`** format.
-- [ ] Document operational limit: if user never opens app for **longer than `exp` allows** (or longer than **pool × daily use** without refresh), prefetch may fail until next open — align with `doc/endorser-jwt-background-prefetch-options.md`.
-
----
-
-## 5. Security notes
-
-- Longer-lived JWTs and **many** tokens increase impact if device is compromised. Mitigations: **encrypted prefs** where possible, **no logging** of full JWTs, **revocation** story with Endorser (key rotation, deny list).
-- Pool regeneration on **login** should replace old pools.
-
----
-
-## 6. Testing plan
-
-| Test | Expected |
-|------|----------|
-| Configure → wait **> 5 min** → prefetch | **200** from `plansLastUpdatedBetween` (Phase A) |
-| Two consecutive **days** with duplicate-JWT staging | **200** both days (Phase B) |
-| Logout | Pool cleared; no stale bearer |
-| Lower `BACKGROUND_JWT_POOL_SIZE` in dev only (below `expiryDays + buffer`) | Expect possible reuse / server duplicate errors — use to reproduce failures |
-
----
-
-## 7. Rollout / staging
-
-1. Implement Phase A behind feature flag **optional** (or direct if low risk).
-2. Verify on **test-api.endorser.ch** with server team.
-3. Phase B behind flag or same release once server duplicate rules are understood.
-
----
-
-## 8. Where plugin documentation lives
-
-| Document | Purpose |
-|----------|---------|
-| **`doc/plan-background-jwt-pool-and-expiry.md`** (this file) | End-to-end app plan: crypto, pool sizing, native host, rollout. |
-| **`doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md`** | **Plugin-only** handoff: extend `configureNativeFetcher`, persist pool, Android/iOS notes — intended for PRs in **daily-notification-plugin** (or Cursor on that repo). |
-
-Keeping them **separate** avoids mixing consumer app tasks with plugin API contract; the plan **links** to the plugin feedback doc for Option B1.
-
----
-
-## 9. References
-
-| Topic | Location |
-|--------|----------|
-| Current 60s `accessToken` | `src/libs/crypto/index.ts` |
-| `createEndorserJwtForDid` | `src/libs/endorserServer.ts` |
-| Native configure | `src/services/notifications/nativeFetcherConfig.ts` |
-| Android HTTP | `android/.../TimeSafariNativeFetcher.java` |
-| Options doc (TTL, refresh, BFF) | `doc/endorser-jwt-background-prefetch-options.md` |
-| Plugin: `configureNativeFetcher` + JWT pool | `doc/plugin-feedback-daily-notification-configureNativeFetcher-jwt-pool.md` |
-
----
-
-*Update this plan when Phase A/B ship or when Endorser policy changes.*

doc/plugin-android-edit-reschedule-alarm-not-firing.md

@@ -1,27 +0,0 @@
-# Plugin: Android — Alarm set after edit doesn’t fire (cancel-before-reschedule)
-
-**Context:** Consuming app (TimeSafari) — user sets reminder at 6:57pm (fires), then edits to 7:00pm. Only one `scheduleDailyNotification` call is made (skipSchedule fix). Logs show "Scheduling OS alarm" and "Updated schedule in database" for 19:00, but the notification never fires at 7:00pm.
-
-**Likely cause (plugin):** In `NotifyReceiver.kt`, before calling `setAlarmClock(pendingIntent)` the code:
-
-1. Creates `pendingIntent` with `PendingIntent.getBroadcast(..., requestCode, intent, FLAG_UPDATE_CURRENT | FLAG_IMMUTABLE)`.
-2. Gets `existingPendingIntent` with `PendingIntent.getBroadcast(..., requestCode, intent, FLAG_NO_CREATE | FLAG_IMMUTABLE)` (same `requestCode`, same `intent`).
-3. If not null: `alarmManager.cancel(existingPendingIntent)` and **`existingPendingIntent.cancel()`**.
-4. Then calls `alarmManager.setAlarmClock(alarmClockInfo, pendingIntent)`.
-
-On Android, PendingIntent equality for caching is based on requestCode and Intent (action, component, etc.), not necessarily all extras. So `existingPendingIntent` is often the **same** (cached) PendingIntent as `pendingIntent`. Then we call **`existingPendingIntent.cancel()`**, which cancels that PendingIntent for future use. We then use the same (now cancelled) PendingIntent in **`setAlarmClock(..., pendingIntent)`**. On some devices/versions, setting an alarm with a cancelled PendingIntent can result in the alarm not firing.
-
-**Suggested fix (plugin repo):**
-
-- Remove the **`existingPendingIntent.cancel()`** call. Use only **`alarmManager.cancel(existingPendingIntent)`** to clear any existing alarm for this requestCode. That way the PendingIntent we pass to `setAlarmClock` is not cancelled; only the previous alarm is removed.
-- Optionally: only run the “cancel existing” block when we know there was a previous schedule (e.g. from DB) for this scheduleId that hasn’t fired yet, so we don’t cancel when the previous alarm already fired (e.g. user edited after first fire).
-
-**Verification:**
-
-- In the consuming app: set reminder 2–3 min from now, let it fire, then edit to 2–3 min from then and save. Capture logcat through the second scheduled time.
-- If the receiver never logs at the second time, the OS didn’t deliver the alarm; fixing the cancel-before-reschedule logic as above should be tried first in the plugin.
-
-**References:**
-
-- CONSUMING_APP_ANDROID_NOTES.md (double schedule, alarm scheduled but not firing).
-- NotifyReceiver.kt around “Cancelling existing alarm before rescheduling” and the following `setAlarmClock` use of `pendingIntent`.

doc/plugin-feedback-android-6-api23-zoneid-fix.md

@@ -1,71 +0,0 @@
-# Plugin fix: Android 6.0 (API 23) compatibility — replace java.time.ZoneId with TimeZone
-
-**Date:** 2026-02-27  
-**Target repo:** daily-notification-plugin  
-**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
-**Platform:** Android
-
----
-
-## Summary
-
-On Android 6.0 (API 23), the plugin crashes at runtime when scheduling a daily notification because it uses `java.time.ZoneId`, which is only available from **API 26**. Replacing that with `java.util.TimeZone.getDefault().getID()` restores compatibility with API 23 and has **no functional impact** on API 26+ (same timezone ID string, same behavior).
-
----
-
-## Problem
-
-- **File:** `android/src/main/java/com/timesafari/dailynotification/NotifyReceiver.kt`
-- **Approximate location:** inside `scheduleExactNotification()`, when building `NotificationContentEntity` (around line 260).
-
-The code uses:
-
-```kotlin
-java.time.ZoneId.systemDefault().id
-```
-
-On API 23 this causes a runtime failure (e.g. `NoClassDefFoundError`) when the scheduling path runs, because `java.time` was added to Android only in API 26 (Oreo).
-
----
-
-## Required change
-
-Replace the `java.time` call with the API-1–compatible equivalent.
-
-**Before:**
-
-```kotlin
-java.time.ZoneId.systemDefault().id
-```
-
-**After:**
-
-```kotlin
-java.util.TimeZone.getDefault().id
-```
-
-Use this in the same place where `NotificationContentEntity` is constructed (the parameter that stores the system timezone ID string). No other code changes are needed.
-
----
-
-## Why this is safe on newer Android
-
-- Both `ZoneId.systemDefault().id` and `TimeZone.getDefault().id` refer to the **same** system default timezone and return the **same** IANA timezone ID string (e.g. `"America/Los_Angeles"`, `"Europe/London"`).
-- Any downstream logic that reads this string (e.g. for display or next-run calculation) behaves identically on API 26+.
-- No change to data format or semantics; this is a backward-compatible drop-in replacement.
-
----
-
-## Verification
-
-1. **Build:** From a consuming app (e.g. crowd-funder-for-time-pwa) with `minSdkVersion = 23`, run a full Android build including the plugin. No compilation errors.
-2. **Runtime on API 23:** On an Android 6.0 device or emulator, enable daily notifications and schedule a time. The app should not crash; the notification should be scheduled and (after the delay) fire.
-3. **Runtime on API 26+:** Confirm scheduling and delivery still work as before on Android 8+.
-
----
-
-## Context (consuming app)
-
-- App and plugin both declare `minSdkVersion = 23` (Android 6.0). AlarmManager, permissions, and notification paths in the plugin are already API-23 safe; this `java.time` usage is the only blocker for running on Android 6.0 devices.
-
-Use this document when applying the fix in the **daily-notification-plugin** repo (e.g. in Cursor). After changing the plugin, update the consuming app’s dependency (e.g. `npm update @timesafari/daily-notification-plugin` or point at the fixed commit), then `npx cap sync android` and rebuild.

doc/plugin-feedback-android-dual-schedule-native-fetch-and-timing.md

@@ -1,126 +0,0 @@
-# Plugin feedback: Android dual schedule — native fetcher not used; fetch timing wrong
-
-**Date:** 2026-03-24 21:56 PST  
-**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
-**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
-**Platform:** Android (Kotlin / Java)  
-**Related:** New Activity notifications (`scheduleDualNotification` / `cancelDualSchedule`)
-
----
-
-## Summary
-
-On Android, the **dual (New Activity) schedule** path is **not** implementing the intended contract:
-
-1. **Prefetch does not call `NativeNotificationContentFetcher`.**  
-   `ScheduleHelper.scheduleDualNotification` delegates fetch to `FetchWorker` (HTTP GET to optional `url`, or **mock JSON** when `url` is absent). The host app’s `TimeSafariNativeFetcher` is **never** invoked. Logcat shows `DNP-FETCH: Starting content fetch from: null, notificationTime=0` and **no** `TimeSafariNativeFetcher` `fetchContent` lines.
-
-2. **Fetch is not scheduled at `contentFetch.schedule` (e.g. T−5 minutes).**  
-   `FetchWorker.enqueueFetch` enqueues **immediate** `OneTimeWorkRequest` work (no `setInitialDelay` aligned to the fetch cron). The **notify** alarm is scheduled correctly for `dual_notify_*`, but there is **no** corresponding alarm/work at the **fetch** cron time. A `dual_fetch_*` row may exist in the DB with `nextRunAt`, but the **actual** fetch runs at **enable/setup time**, not at T−5.
-
-3. **Cache vs `DualScheduleHelper` / `contentTimeout`.**  
-   `DualScheduleHelper.resolveDualContentBlocking` only uses `contentCache` when the latest fetch is within `relationship.contentTimeout` (e.g. 5 minutes). If fetch runs **once at setup** and notify fires **~9+ minutes later**, cache is **stale** → `useCache=false` → default title/body from `userNotification`, even when mock payload was stored.
-
-**Recommended direction (plugin):**
-
-- For dual schedule when **no HTTP `url`** is configured (or when a flag indicates native mode), run **`NativeNotificationContentFetcher.fetchContent(FetchContext)`** (same path as `DailyNotificationFetchWorker` uses), persist results into the same `contentCache` / pipeline `DualScheduleHelper` expects.
-- **Schedule** that work (or an alarm that enqueues it) **at** `calculateNextRunTime(contentFetch.schedule)` — i.e. **before** the notify alarm, typically **5 minutes** earlier per app cron (see consuming app `timeToCronFiveMinutesBefore`).
-- Optionally align **one** scheduling mechanism: either exact alarm for fetch + notify, or WorkManager with **initial delay** to the next fetch instant (and reschedule after run).
-
----
-
-## Symptoms (consuming app + logcat)
-
-- Notification shows **default** copy from `userNotification` (`title` / `body` from `buildDualScheduleConfig`), not API-derived or native “No updates” copy.
-- Logcat: `DNP-DUAL: Resolved dual content: useCache=false` at notify time.
-- Logcat: `DNP-FETCH: Starting content fetch from: null, notificationTime=0` followed by `Content fetch completed successfully` **at schedule/setup time**, not at T−5.
-- **No** `TimeSafariNativeFetcher` `fetchContent START` / `POST …/plansLastUpdatedBetween` during prefetch window (host registers `NativeNotificationContentFetcher` and logs on configure + fetch).
-- **No** activity at the **prefetch cron** time (e.g. 19:05 for notify at 19:10); only **notify** fires at T.
-
----
-
-## What the consuming app sends (contract)
-
-**File:** `src/services/notifications/dualScheduleConfig.ts`
-
-- `contentFetch.enabled: true`
-- `contentFetch.schedule`: cron **5 minutes before** `userNotification.schedule` (e.g. `"25 19 * * *"` for notify `"30 19 * * *"`).
-- **No** `contentFetch.url` — intended to use **native** Endorser API via `configureNativeFetcher` + `NativeNotificationContentFetcher`.
-- `relationship.autoLink: true`, `relationship.contentTimeout: 5 * 60 * 1000`, `fallbackBehavior: "show_default"`.
-
-**Host app:** `android/.../TimeSafariNativeFetcher.java` implements `NativeNotificationContentFetcher` and calls `POST /api/v2/report/plansLastUpdatedBetween` with starred plan IDs from `updateStarredPlans`.
-
----
-
-## Root cause (plugin code — paths to review)
-
-These paths are from a local clone of **daily-notification-plugin**; line numbers may drift.
-
-### 1. `FetchWorker` is URL/mock-only; does not call native fetcher
-
-`android/src/main/java/org/timesafari/dailynotification/FetchWorker.kt`
-
-- `enqueueFetch` passes `config.url` into `InputData`; `doWork` logs `Starting content fetch from: $url`.
-- `fetchContent(url, …)` when `url` is null/blank returns **`generateMockContent()`** — never calls `DailyNotificationPlugin.getNativeFetcherStatic().fetchContent(...)`.
-
-### 2. `scheduleDualNotification` runs fetch work immediately, not at fetch cron
-
-`android/src/main/java/org/timesafari/dailynotification/DailyNotificationPlugin.kt` — `object ScheduleHelper`, `suspend fun scheduleDualNotification(...)`
-
-- Calls `scheduleFetch(context, contentFetchConfig)` which resolves to `FetchWorker.scheduleFetchForDual` → `enqueueFetch` **without** delay tied to `contentFetchConfig.schedule`.
-- Schedules **notify** via `NotifyReceiver.scheduleExactNotification` for `dual_notify_*` at `calculateNextRunTime(userNotificationConfig.schedule)`.
-- Persists `dual_fetch_*` with `nextRunAt = calculateNextRunTime(contentFetchConfig.schedule)` but **no** matching alarm/work is scheduled for that instant in the current flow (as observed).
-
-### 3. Native fetcher exists elsewhere
-
-`android/src/main/java/org/timesafari/dailynotification/DailyNotificationFetchWorker.java`
-
-- Contains logic to call `NativeNotificationContentFetcher.fetchContent(FetchContext)` (with timeout). Dual schedule **does not** enqueue this worker for the TimeSafari `contentFetch` payload.
-
-### 4. `DualScheduleHelper` behavior is consistent with “wrong fetch time”
-
-`android/src/main/java/org/timesafari/dailynotification/DualScheduleHelper.kt`
-
-- Uses latest `contentCache` only if `(now - fetchedAt) <= contentTimeoutMs`. If fetch ran at setup and notify is **later** than `contentTimeout`, **cache is ignored** → `useCache=false` in logs.
-
----
-
-## Acceptance criteria (plugin)
-
-After a fix, on a device with:
-
-- `configureNativeFetcher` + `updateStarredPlans` called (host app),
-- `scheduleDualNotification` with `contentFetch.enabled: true`, no `url`, cron 5 min before notify,
-
-then:
-
-1. **At or before** the notify fire time, **within** `contentTimeout`, the cache used by `DualScheduleHelper` reflects **native** fetch results when the API returns data (or empty), not only mock JSON.
-2. Logcat **includes** host tag `TimeSafariNativeFetcher` with `fetchContent START` (or equivalent) **when** prefetch runs, **or** plugin logs an explicit `NativeNotificationContentFetcher` invocation.
-3. Prefetch **does not** run only at **INITIAL_SETUP**; it runs at the **next** occurrence of `contentFetch.schedule` (and reschedules for the following day after success, same as notify rollover).
-4. **Optional:** If `url` is set, preserve HTTP GET behavior; if `url` is absent and native fetcher is registered, use native path.
-
----
-
-## References in consuming app
-
-| Topic | Location |
-|--------|----------|
-| Dual config builder | `src/services/notifications/dualScheduleConfig.ts` |
-| `scheduleDualNotification` call | `src/views/AccountViewView.vue` (`scheduleNewActivityDualNotification`, `editNewActivityNotification`) |
-| Native fetcher | `android/app/src/main/java/app/timesafari/TimeSafariNativeFetcher.java` |
-| Registration | `MainActivity` / plugin init (host registers `DailyNotificationPlugin.setNativeFetcher`) |
-
----
-
-## Notes for Cursor / implementers
-
-- **Do not** assume `contentFetch.url` is present; TimeSafari intentionally omits it for native API.
-- **Reuse** the same `FetchContext` / timeout semantics as `DailyNotificationFetchWorker` where possible to avoid two divergent native fetch implementations.
-- After changing timing, **verify** `WorkManager` unique work name `fetch_dual` / `cancelDualSchedule` still cancel only dual fetch and do not break daily reminder.
-
----
-
-## Related docs in this repo
-
-- `doc/notification-from-api-call.md` — integration plan for API-driven New Activity.
-- `doc/plugin-feedback-android-scheduleDualNotification-contentFetch-json.md` — optional `timeout` / `retry*` JSON parsing (already addressed on the plugin side).

doc/plugin-feedback-android-duplicate-reminder-notification.md

@@ -1,114 +0,0 @@
-# Plugin feedback: Android duplicate reminder notification on first-time setup
-
-**Date:** 2026-02-18  
-**Generated:** 2026-02-18 17:47:06 PST  
-**Target repo:** `@timesafari/daily-notification-plugin` (https://gitea.anomalistdesign.com/trent_larson/daily-notification-plugin)  
-**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
-**Platform:** Android
-
-## Summary
-
-When the user sets a **Reminder Notification for the first time** (toggle on → set message and time in `PushNotificationPermission`), **two notifications** fire at the scheduled time:
-
-1. **Correct one:** User’s chosen title/message, from the static reminder alarm (`scheduleId` = `daily_timesafari_reminder`).
-2. **Extra one:** Fallback message (“Daily Update” / “🌅 Good morning! Ready to make today amazing?”), from a second alarm that uses a **UUID** as `notification_id`.
-
-When the user **edits** an existing reminder (Edit Notification Details), only one notification fires. The duplicate only happens on **initial** setup.
-
-The app calls `scheduleDailyNotification` **once** per user action in both flows (first-time and edit). The duplicate is caused inside the plugin by the **prefetch worker** scheduling a second alarm via the legacy `DailyNotificationScheduler`.
-
----
-
-## Evidence from Logcat
-
-Filter: `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
-
-- **17:42:34** – Single call from app: plugin schedules the static reminder alarm (`scheduleId=daily_timesafari_reminder`, source=INITIAL_SETUP). One OS alarm is scheduled.
-- **17:45:00** – **Two** `RECEIVE_START` events:
-  - First: `display=5e373fd1-0f08-4e8f-b166-cfd46d694d82` (UUID).
-  - Second: `static_reminder id=daily_timesafari_reminder`.
-- Both run in parallel: Worker for UUID shows `DN|JIT_FRESH skip=true` and displays; Worker for `daily_timesafari_reminder` shows `DN|DISPLAY_STATIC_REMINDER` and displays. So two notifications are shown.
-
-Conclusion: two different PendingIntents fire at the same time: one with `notification_id` = UUID, one with `notification_id` = `daily_timesafari_reminder`.
-
----
-
-## Root cause (plugin side)
-
-1. **ScheduleHelper.scheduleDailyNotification** (e.g. in `DailyNotificationPlugin.kt`):
-   - Cancels existing alarm for `scheduleId`.
-   - Schedules **one** alarm via **NotifyReceiver.scheduleExactNotification** with `reminderId = scheduleId`, `scheduleId = scheduleId`, `isStaticReminder = true` (INITIAL_SETUP). That alarm carries title/body in the intent and is the “correct” notification.
-   - Enqueues **DailyNotificationFetchWorker** (prefetch) to run 2 minutes before the same time.
-
-2. **DailyNotificationFetchWorker** runs ~2 minutes before the display time:
-   - Tries to fetch content (e.g. native fetcher). For a static-reminder-only app (no URL, no fetcher returning content), the fetch returns empty/null.
-   - Goes to **handleFailedFetch** → **useFallbackContent** → **getFallbackContent** → **createEmergencyFallbackContent(scheduledTime)**.
-   - **createEmergencyFallbackContent** builds a `NotificationContent()` (default constructor), which assigns a **random UUID** as `id`, and sets title “Daily Update” and body “🌅 Good morning! Ready to make today amazing?”.
-   - **useFallbackContent** then calls **scheduleNotificationIfNeeded(fallbackContent)**.
-
-3. **scheduleNotificationIfNeeded** uses the **legacy DailyNotificationScheduler** (AlarmManager) to schedule **another** alarm at the **same** `scheduledTime`, with `notification_id` = that UUID.
-
-So at fire time there are two alarms:
-
-- NotifyReceiver’s alarm: `notification_id` = `daily_timesafari_reminder`, `is_static_reminder` = true → correct user message.
-- DailyNotificationScheduler’s alarm: `notification_id` = UUID → fallback message.
-
-The prefetch path is intended for “fetch content then display” flows. For **static reminder** schedules, the display is already fully handled by the single NotifyReceiver alarm; the prefetch worker should not schedule a second alarm.
-
----
-
-## Why edit doesn’t show the duplicate (in observed behavior)
-
-On edit, the app still calls the plugin once and the plugin again enqueues the prefetch worker. Possible reasons the duplicate is less obvious on edit:
-
-- Different timing (e.g. user sets a time further out, or doesn’t wait for the second notification).
-- Or the first-time run leaves the prefetch/legacy path in a state where the duplicate only appears on first setup.
-
-Regardless, the **correct fix** is to ensure that for static-reminder schedules the prefetch worker never schedules a second alarm.
-
----
-
-## Recommended fix (in the plugin)
-
-**Option A (recommended): Do not enqueue prefetch for static reminder schedules**
-
-In **ScheduleHelper.scheduleDailyNotification** (or equivalent), when scheduling a **static reminder** (title/body from app, no URL, display already in the intent), **do not** enqueue `DailyNotificationFetchWorker` for that run. The prefetch is for “fetch content then show”; for static reminders there is nothing to fetch and the only alarm should be the one from NotifyReceiver.
-
-- No new inputData flags needed.
-- No change to DailyNotificationFetchWorker semantics for other flows.
-
-**Option B: Prefetch worker skips scheduling when display is already scheduled**
-
-- When enqueueing the prefetch work for a static-reminder schedule, pass an input flag (e.g. `display_already_scheduled` or `is_static_reminder_schedule` = true).
-- In **DailyNotificationFetchWorker**, in **useFallbackContent** (and anywhere else that calls **scheduleNotificationIfNeeded** for this work item), if that flag is set, **do not** call **scheduleNotificationIfNeeded**.
-- Ensures only the NotifyReceiver alarm fires for that time.
-
-Option A is simpler and matches the semantics: static reminder = one alarm, no prefetch.
-
----
-
-## App-side behavior (no change required)
-
-- **First-time reminder:** Account view opens `PushNotificationPermission` without `skipSchedule`. User sets time/message and confirms. Dialog’s `turnOnNativeNotifications` calls `NotificationService.scheduleDailyNotification(...)` **once** and then the callback saves settings. No second schedule from the app.
-- **Edit reminder:** Account view opens the dialog with `skipSchedule: true`. Only the parent’s callback runs; it calls `cancelDailyNotification()` (on iOS) then `scheduleDailyNotification(...)` **once**. No double schedule from the app.
-
-So the duplicate is entirely due to the plugin’s prefetch worker scheduling an extra alarm via the legacy scheduler; fixing it in the plugin as above will resolve the issue.
-
----
-
-## Files to consider in the plugin
-
-- **ScheduleHelper.scheduleDailyNotification** (e.g. in `DailyNotificationPlugin.kt`): where the single NotifyReceiver alarm and the prefetch work are enqueued. Either skip enqueueing prefetch for static reminder (Option A), or add inputData for “display already scheduled” (Option B).
-- **DailyNotificationFetchWorker**: `useFallbackContent` → `scheduleNotificationIfNeeded`; if using Option B, skip `scheduleNotificationIfNeeded` when the new flag is set.
-- **DailyNotificationScheduler** (legacy): used by `scheduleNotificationIfNeeded` to add the second (UUID) alarm; no change required if the worker simply stops calling it for static-reminder schedules.
-
----
-
-## Verification
-
-After the fix:
-
-1. **First-time:** Turn on Reminder Notification, set message and time (e.g. 2–3 minutes ahead). Wait until the scheduled time. **Only one** notification should appear, with the user’s message.
-2. Logcat should show a single `RECEIVE_START` at that time (e.g. `static_reminder id=daily_timesafari_reminder`), and no second `display=<uuid>` for the same time.
-
-You can reuse the same Logcat filter as above to confirm a single receiver run per scheduled time.

doc/plugin-feedback-android-exact-alarm-settings.md

@@ -1,74 +0,0 @@
-# Plugin feedback: Android exact alarm — stop opening Settings automatically
-
-**Date:** 2026-03-09  
-**Target repo:** daily-notification-plugin  
-**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
-**Platform:** Android
-
-## Summary
-
-When the consuming app calls `scheduleDailyNotification()` after the user has granted `POST_NOTIFICATIONS`, the plugin checks whether **exact alarms** can be scheduled (Android 12+). If not, it **opens the system Settings** (exact-alarm or app-details screen) and **rejects** the call. This is intrusive: the app prefers to schedule without forcing the user into Settings, and to inform the user about exact alarms in its own UI (e.g. a note in the success message).
-
-**Requested change:** Remove the automatic opening of Settings for exact alarm permission from `scheduleDailyNotification()`. Either:
-
-- **Option A (preferred):** Do not open Settings and do not reject when exact alarm is not granted. Proceed with scheduling (using inexact alarms if necessary when exact is unavailable), and let the consuming app handle any UX (e.g. optional hint to enable exact alarms).
-- **Option B:** Do not open Settings, but still reject with a clear error code/message when exact alarm is required and not granted, so the app can show its own message or deep-link to Settings if desired.
-
----
-
-## Where this lives in the plugin
-
-**File:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`  
-**Method:** `scheduleDailyNotification(call: PluginCall)`  
-**Lines:** ~1057–1109 (exact line numbers may shift with edits)
-
-Current behavior:
-
-1. At the start of `scheduleDailyNotification()`, the plugin calls `canScheduleExactAlarms(context)`.
-2. If `false`:
-   - If Android S+ and `canRequestExactAlarmPermission(context)` is true: it builds `Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM`, calls `context.startActivity(intent)`, logs **"Exact alarm permission required. Opened Settings for user to grant permission."** (tag `DNP-PLUGIN`), and rejects with `EXACT_ALARM_PERMISSION_REQUIRED`.
-   - Else: it opens app details (`Settings.ACTION_APPLICATION_DETAILS_SETTINGS`), logs **"Exact alarm permission denied. Directing user to app settings."**, and rejects with `PERMISSION_DENIED`.
-3. Only if exact alarms are allowed does the plugin continue to schedule.
-
-So the **exact alarms** feature here is: **gate scheduling on exact alarm permission and, when not granted, open Settings and reject.**
-
----
-
-## Evidence from consumer app (logcat)
-
-Filter: `DNP-PLUGIN`, `DNP-SCHEDULE`, `DailyNotificationWorker`, `DailyNotificationReceiver`.
-
-Typical sequence when user enables daily notification:
-
-1. `DNP-PLUGIN: Created pending permission request: ... type=POST_NOTIFICATIONS`
-2. User grants notification permission.
-3. `DNP-PLUGIN: Resolving pending POST_NOTIFICATIONS request on resume: granted=true`
-4. App calls `scheduleDailyNotification(...)`.
-5. `DNP-PLUGIN: Exact alarm permission required. Opened Settings for user to grant permission.`
-
-The consumer app does **not** call any plugin API to “request exact alarm” or “open exact alarm settings”; it only calls `requestPermissions()` (POST_NOTIFICATIONS) and then `scheduleDailyNotification()`. The plugin’s own guard in `scheduleDailyNotification()` is what opens Settings.
-
----
-
-## Consumer app context
-
-- **Permission flow:** The app requests `POST_NOTIFICATIONS` via the plugin’s `requestPermissions()`, then calls `scheduleDailyNotification()`. It does not request exact alarm permission itself.
-- **UX:** The app already shows an optional note when exact alarm is not granted (e.g. “If notifications don’t appear, enable ‘Exact alarms’ in Android Settings → Apps → TimeSafari → App settings”). It does not want the plugin to open Settings automatically.
-- **Manifest:** The app declares `SCHEDULE_EXACT_ALARM` in its AndroidManifest; the issue is only the **automatic redirect to Settings** and the **reject** when exact alarm is not yet granted.
-
----
-
-## Suggested plugin changes
-
-1. **In `scheduleDailyNotification()`:** Remove the block that opens Settings and rejects when `!canScheduleExactAlarms(context)` (the block ~1057–1109). Do **not** call `startActivity` for `ACTION_REQUEST_SCHEDULE_EXACT_ALARM` or `ACTION_APPLICATION_DETAILS_SETTINGS` from this method.
-2. **Scheduling when exact alarm is not granted:** Prefer Option A: continue and schedule even when exact alarms are not allowed (e.g. use inexact/alarm manager APIs that don’t require exact alarm, or document that timing may be approximate). If the plugin must reject when exact is required, use Option B: reject with a specific error code/message and no `startActivity`.
-3. **Leave other APIs unchanged:** Methods such as `openExactAlarmSettings()` or `requestExactAlarmPermission()` can remain for apps that explicitly want to send the user to Settings; the change is only to stop doing it automatically inside `scheduleDailyNotification()`.
-
----
-
-## Relation to existing docs
-
-- **Plugin:** `doc/daily-notification-plugin-android-receiver-issue.md` and `doc/daily-notification-plugin-checklist.md` describe use of `SCHEDULE_EXACT_ALARM` (not `USE_EXACT_ALARM`). This feedback does not change that; it only asks to stop auto-opening Settings in `scheduleDailyNotification()`.
-- **Consumer app:** `doc/notification-permissions-and-rollovers.md` describes the permission flow; `doc/NOTIFICATION_TROUBLESHOOTING.md` mentions exact alarms for user guidance.
-
-Use this document when implementing the change in the **daily-notification-plugin** repo (e.g. with Cursor). After changing the plugin, update the consuming app’s dependency (e.g. `npm update @timesafari/daily-notification-plugin`), then `npx cap sync android` and rebuild.

doc/plugin-feedback-android-parseUserNotificationConfig-optional-fields.md

@@ -1,99 +0,0 @@
-# Plugin feedback: Android `parseUserNotificationConfig` — optional fields vs `getBoolean` / `getString`
-
-**Date:** 2026-03-20 21:11 PST  
-**Target repo:** `@timesafari/daily-notification-plugin` (daily-notification-plugin)  
-**Consuming app:** crowd-funder-for-time-pwa (TimeSafari)  
-**Platform:** Android (Kotlin)  
-**Related:** Same class of issue as [plugin-feedback-android-scheduleDualNotification-contentFetch-json.md](./plugin-feedback-android-scheduleDualNotification-contentFetch-json.md) (`contentFetch` / `parseContentFetchConfig`).
-
----
-
-## Summary
-
-`DailyNotificationPlugin.parseUserNotificationConfig()` uses **`JSObject` / `JSONObject` strict getters** for fields that the published TypeScript **`UserNotificationConfig`** marks as **optional** (`sound?`, `vibration?`, `priority?`, `title?`, `body?`). If a key is omitted, Android throws **`JSONException`** (e.g. *No value for vibration*), and `scheduleDualNotification` fails before scheduling.
-
-**Recommended direction (plugin):** Align Kotlin parsing with `dist/esm/definitions.d.ts` by using **optional reads + defaults**, consistent with the fix already applied for `parseContentFetchConfig` (e.g. `optIntOrNull`, or Capacitor/JSON equivalents for booleans and strings).
-
-**Recommended direction (app / already done in TimeSafari):** Send explicit `sound`, `vibration`, and `priority` (and title/body) in `buildDualScheduleConfig()` so **older plugin builds** that still use strict getters continue to work.
-
-**Does it make sense to change both sides?** **Yes** — same reasoning as for `contentFetch`: the plugin should match its public contract; the app can stay explicit for compatibility and clarity.
-
----
-
-## Symptoms (consuming app)
-
-- In-app toast: *“Could not schedule New Activity notification. Please try again.”* (generic catch after `scheduleDualNotification` rejects.)
-- Logcat:
-
-```text
-E DNP-PLUGIN: Schedule dual notification error
-E DNP-PLUGIN: org.json.JSONException: No value for vibration
-E DNP-PLUGIN:   at org.json.JSONObject.getBoolean(JSONObject.java:419)
-E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.parseUserNotificationConfig(DailyNotificationPlugin.kt:2428)
-E DNP-PLUGIN:   at org.timesafari.dailynotification.DailyNotificationPlugin.scheduleDualNotification(DailyNotificationPlugin.kt:1392)
-```
-
-(First failure observed after `contentFetch` timeouts were fixed was **`vibration`**; the same pattern can affect **`sound`** or **`priority`** if those keys are omitted.)
-
----
-
-## Root cause
-
-### Published TypeScript contract (`UserNotificationConfig`)
-
-From `definitions.d.ts` (representative):
-
-- `title?`, `body?`, `sound?`, `vibration?`, `priority?` — all optional.
-
-### Current Android implementation (strict)
-
-In `DailyNotificationPlugin.kt`, `parseUserNotificationConfig` (line numbers approximate; search for `parseUserNotificationConfig`):
-
-```kotlin
-private fun parseUserNotificationConfig(configJson: JSObject): UserNotificationConfig {
-    return UserNotificationConfig(
-        enabled = configJson.getBoolean("enabled") ?: true,
-        schedule = configJson.getString("schedule") ?: "0 9 * * *",
-        title = configJson.getString("title"),
-        body = configJson.getString("body"),
-        sound = configJson.getBoolean("sound"),
-        vibration = configJson.getBoolean("vibration"),
-        priority = configJson.getString("priority")
-    )
-}
-```
-
-- **`getBoolean("vibration")`** (and **`getBoolean("sound")`**) throw if the key is **missing** — optional in TS, required at runtime on Android.
-- **`getString("title")`**, **`getString("body")`**, **`getString("priority")`** likewise throw if missing (depending on `JSObject` / `JSONObject` behavior for absent keys).
-
-So minimal or TS-faithful payloads omit `vibration` → immediate `JSONException`.
-
----
-
-## Plugin-side recommendations
-
-1. **Treat `UserNotificationConfig` optional fields as optional on Android**, mirroring `definitions.d.ts`:
-   - **`vibration`:** e.g. `optBoolean` / nullable + default **`true`** (or `false` if that matches product default — document the default).
-   - **`sound`:** same pattern; default **`true`** is typical for notifications.
-   - **`priority`:** optional string with default **`"normal"`** (or map from TS union).
-   - **`title` / `body`:** if TS allows omission, use optional reads + defaults consistent with dual-schedule UX (or reject with a clear `call.reject` message instead of a raw `JSONException`).
-
-2. **Reuse the same helper style** as `parseContentFetchConfig` after the timeout fix (`optIntOrNull`, etc.) so one codebase convention applies to all dual-schedule JSON parsing.
-
-3. **Tests:** Unit or integration test that calls `scheduleDualNotification` with a **minimal** `userNotification` object (only what TS strictly requires, if anything) and asserts scheduling succeeds on Android.
-
-4. **iOS parity:** If iOS already accepts omitted `vibration` / `sound`, Android should match; if not, align both platforms to the same `UserNotificationConfig` rules.
-
----
-
-## App-side note (TimeSafari)
-
-`src/services/notifications/dualScheduleConfig.ts` — `buildDualScheduleConfig()` now includes **`vibration: true`** (with `sound: true`) so current native code paths succeed. Keeping this explicit is still recommended even after the plugin is fixed.
-
----
-
-## References
-
-- Plugin: `android/.../DailyNotificationPlugin.kt` — `parseUserNotificationConfig`
-- TS: `dist/esm/definitions.d.ts` — `UserNotificationConfig`, `DualScheduleConfiguration`
-- App: `src/services/notifications/dualScheduleConfig.ts` — `buildDualScheduleConfig`