Compare commits

..

1 Commits

Author SHA1 Message Date
Matthew Raymer
2e290ad488 grr: experimental diagnosis and fix for build:web:serve 2025-07-18 09:40:12 +00:00
356 changed files with 38551 additions and 9827 deletions

View File

@@ -1,6 +1,7 @@
---
globs: **/db/databaseUtil.ts, **/interfaces/absurd-sql.d.ts, **/src/registerSQLWorker.js, **/services/AbsurdSqlDatabaseService.ts
alwaysApply: false
description:
globs:
alwaysApply: true
---
# Absurd SQL - Cursor Development Guide

View File

@@ -1,63 +0,0 @@
# ADR Template
## ADR-XXXX-YY-ZZ: [Short Title]
**Date:** YYYY-MM-DD
**Status:** [PROPOSED | ACCEPTED | REJECTED | DEPRECATED | SUPERSEDED]
**Deciders:** [List of decision makers]
**Technical Story:** [Link to issue/PR if applicable]
## Context
[Describe the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.]
## Decision
[Describe our response to these forces. We will use the past tense ("We will...").]
## Consequences
### Positive
- [List positive consequences]
### Negative
- [List negative consequences or trade-offs]
### Neutral
- [List neutral consequences or notes]
## Alternatives Considered
- **Alternative 1:** [Description] - [Why rejected]
- **Alternative 2:** [Description] - [Why rejected]
- **Alternative 3:** [Description] - [Why rejected]
## Implementation Notes
[Any specific implementation details, migration steps, or technical considerations]
## References
- [Link to relevant documentation]
- [Link to related ADRs]
- [Link to external resources]
## Related Decisions
- [List related ADRs or decisions]
---
## Usage Guidelines
1. **Copy this template** for new ADRs
2. **Number sequentially** (ADR-001, ADR-002, etc.)
3. **Use descriptive titles** that clearly indicate the decision
4. **Include all stakeholders** in the deciders list
5. **Link to related issues** and documentation
6. **Update status** as decisions evolve
7. **Store in** `doc/architecture-decisions/` directory
description:
globs:
alwaysApply: false
---

View File

@@ -1,172 +0,0 @@
---
description:
globs:
alwaysApply: true
---
# TimeSafari Cross-Platform Architecture Guide
## 1. Platform Support Matrix
| Feature | Web (PWA) | Capacitor (Mobile) | Electron (Desktop) |
|---------|-----------|--------------------|-------------------|
| QR Code Scanning | WebInlineQRScanner | @capacitor-mlkit/barcode-scanning | Not Implemented |
| Deep Linking | URL Parameters | App URL Open Events | Not Implemented |
| File System | Limited (Browser API) | Capacitor Filesystem | Electron fs |
| Camera Access | MediaDevices API | Capacitor Camera | Not Implemented |
| Platform Detection | Web APIs | Capacitor.isNativePlatform() | process.env checks |
---
## 2. Project Structure
### Core Directories
```
src/
├── components/ # Vue components
├── services/ # Platform services and business logic
├── views/ # Page components
├── router/ # Vue router configuration
├── types/ # TypeScript type definitions
├── utils/ # Utility functions
├── lib/ # Core libraries
├── platforms/ # Platform-specific implementations
├── electron/ # Electron-specific code
├── constants/ # Application constants
├── db/ # Database related code
├── interfaces/ # TypeScript interfaces
└── assets/ # Static assets
```
### Entry Points
- `main.ts` → Base entry
- `main.common.ts` → Shared init
- `main.capacitor.ts` → Mobile entry
- `main.electron.ts` → Electron entry
- `main.web.ts` → Web entry
---
## 3. Service Architecture
### Service Organization
```tree
services/
├── QRScanner/
│ ├── WebInlineQRScanner.ts
│ └── interfaces.ts
├── platforms/
│ ├── WebPlatformService.ts
│ ├── CapacitorPlatformService.ts
│ └── ElectronPlatformService.ts
└── factory/
└── PlatformServiceFactory.ts
```
### Factory Pattern
Use a **singleton factory** to select platform services via `process.env.VITE_PLATFORM`.
---
## 4. Feature Guidelines
### QR Code Scanning
- Define `QRScannerService` interface.
- Implement platform-specific classes (`WebInlineQRScanner`, Capacitor, etc).
- Provide `addListener` and `onStream` hooks for composability.
### Deep Linking
- URL format: `timesafari://<route>[/<param>][?query=value]`
- Web: `router.beforeEach` → parse query
- Capacitor: `App.addListener("appUrlOpen", …)`
---
## 5. Build Process
- `vite.config.common.mts` → shared config
- Platform configs: `vite.config.web.mts`, `.capacitor.mts`, `.electron.mts`
- Use `process.env.VITE_PLATFORM` for conditional loading.
```bash
npm run build:web
npm run build:capacitor
npm run build:electron
```
---
## 6. Testing Strategy
- **Unit tests** for services.
- **Playwright** for Web + Capacitor:
- `playwright.config-local.ts` includes web + Pixel 5.
- **Electron tests**: add `spectron` or Playwright-Electron.
- Mark tests with platform tags:
```ts
test.skip(!process.env.MOBILE_TEST, "Mobile-only test");
```
> 🔗 **Human Hook:** Before merging new tests, hold a short sync (≤15 min) with QA to align on coverage and flaky test risks.
---
## 7. Error Handling
- Global Vue error handler → logs with component name.
- Platform-specific wrappers log API errors with platform prefix (`[Capacitor API Error]`, etc).
- Use structured logging (not `console.log`).
---
## 8. Best Practices
- Keep platform code **isolated** in `platforms/`.
- Always define a **shared interface** first.
- Use feature detection, not platform detection, when possible.
- Dependency injection for services → improves testability.
- Maintain **Competence Hooks** in PRs (23 prompts for dev discussion).
---
## 9. Dependency Management
- Key deps: `@capacitor/core`, `electron`, `vue`.
- Use conditional `import()` for platform-specific libs.
---
## 10. Security Considerations
- **Permissions**: Always check + request gracefully.
- **Storage**: Secure storage for sensitive data; encrypt when possible.
- **Audits**: Schedule quarterly security reviews.
---
## 11. ADR Process
- All major architecture choices → log in `doc/adr/`.
- Use ADR template with Context, Decision, Consequences, Status.
- Link related ADRs in PR descriptions.
> 🔗 **Human Hook:** When proposing a new ADR, schedule a 30-min design sync for discussion, not just async review.
---
## 12. Collaboration Hooks
- **QR features**: Sync with Security before merging → permissions & privacy.
- **New platform builds**: Demo in team meeting → confirm UX differences.
- **Critical ADRs**: Present in guild or architecture review.
---
# Self-Check
- [ ] Does this feature implement a shared interface?
- [ ] Are fallbacks + errors handled gracefully?
- [ ] Have relevant ADRs been updated/linked?
- [ ] Did I add competence hooks or prompts for the team?
- [ ] Was human interaction (sync/review/demo) scheduled?

View File

@@ -0,0 +1,287 @@
---
description:
globs:
alwaysApply: true
---
# TimeSafari Cross-Platform Architecture Guide
## 1. Platform Support Matrix
| Feature | Web (PWA) | Capacitor (Mobile) | Electron (Desktop) |
|---------|-----------|-------------------|-------------------|
| QR Code Scanning | WebInlineQRScanner | @capacitor-mlkit/barcode-scanning | Not Implemented |
| Deep Linking | URL Parameters | App URL Open Events | Not Implemented |
| File System | Limited (Browser API) | Capacitor Filesystem | Electron fs |
| Camera Access | MediaDevices API | Capacitor Camera | Not Implemented |
| Platform Detection | Web APIs | Capacitor.isNativePlatform() | process.env checks |
## 2. Project Structure
### 2.1 Core Directories
```
src/
├── components/ # Vue components
├── services/ # Platform services and business logic
├── views/ # Page components
├── router/ # Vue router configuration
├── types/ # TypeScript type definitions
├── utils/ # Utility functions
├── lib/ # Core libraries
├── platforms/ # Platform-specific implementations
├── electron/ # Electron-specific code
├── constants/ # Application constants
├── db/ # Database related code
├── interfaces/ # TypeScript interfaces and type definitions
└── assets/ # Static assets
```
### 2.2 Entry Points
```
src/
├── main.ts # Base entry
├── main.common.ts # Shared initialization
├── main.capacitor.ts # Mobile entry
├── main.electron.ts # Electron entry
└── main.web.ts # Web/PWA entry
```
### 2.3 Build Configurations
```
root/
├── vite.config.common.mts # Shared config
├── vite.config.capacitor.mts # Mobile build
├── vite.config.electron.mts # Electron build
└── vite.config.web.mts # Web/PWA build
```
## 3. Service Architecture
### 3.1 Service Organization
```
services/
├── QRScanner/ # QR code scanning service
│ ├── WebInlineQRScanner.ts
│ └── interfaces.ts
├── platforms/ # Platform-specific services
│ ├── WebPlatformService.ts
│ ├── CapacitorPlatformService.ts
│ └── ElectronPlatformService.ts
└── factory/ # Service factories
└── PlatformServiceFactory.ts
```
### 3.2 Service Factory Pattern
```typescript
// PlatformServiceFactory.ts
export class PlatformServiceFactory {
private static instance: PlatformService | null = null;
public static getInstance(): PlatformService {
if (!PlatformServiceFactory.instance) {
const platform = process.env.VITE_PLATFORM || "web";
PlatformServiceFactory.instance = createPlatformService(platform);
}
return PlatformServiceFactory.instance;
}
}
```
## 4. Feature Implementation Guidelines
### 4.1 QR Code Scanning
1. **Service Interface**
```typescript
interface QRScannerService {
checkPermissions(): Promise<boolean>;
requestPermissions(): Promise<boolean>;
isSupported(): Promise<boolean>;
startScan(): Promise<void>;
stopScan(): Promise<void>;
addListener(listener: ScanListener): void;
onStream(callback: (stream: MediaStream | null) => void): void;
cleanup(): Promise<void>;
}
```
2. **Platform-Specific Implementation**
```typescript
// WebInlineQRScanner.ts
export class WebInlineQRScanner implements QRScannerService {
private scanListener: ScanListener | null = null;
private isScanning = false;
private stream: MediaStream | null = null;
private events = new EventEmitter();
// Implementation of interface methods
}
```
### 4.2 Deep Linking
1. **URL Structure**
```typescript
// Format: timesafari://<route>[/<param>][?queryParam1=value1]
interface DeepLinkParams {
route: string;
params?: Record<string, string>;
query?: Record<string, string>;
}
```
2. **Platform Handlers**
```typescript
// Capacitor
App.addListener("appUrlOpen", handleDeepLink);
// Web
router.beforeEach((to, from, next) => {
handleWebDeepLink(to.query);
});
```
## 5. Build Process
### 5.1 Environment Configuration
```typescript
// vite.config.common.mts
export function createBuildConfig(mode: string) {
return {
define: {
'process.env.VITE_PLATFORM': JSON.stringify(mode),
// PWA is automatically enabled for web platforms via build configuration
__IS_MOBILE__: JSON.stringify(isCapacitor),
__USE_QR_READER__: JSON.stringify(!isCapacitor)
}
};
}
```
### 5.2 Platform-Specific Builds
```bash
# Build commands from package.json
"build:web": "vite build --config vite.config.web.mts",
"build:capacitor": "vite build --config vite.config.capacitor.mts",
"build:electron": "vite build --config vite.config.electron.mts"
```
## 6. Testing Strategy
### 6.1 Test Configuration
```typescript
// playwright.config-local.ts
const config: PlaywrightTestConfig = {
projects: [
{
name: 'web',
use: { browserName: 'chromium' }
},
{
name: 'mobile',
use: { ...devices['Pixel 5'] }
}
]
};
```
### 6.2 Platform-Specific Tests
```typescript
test('QR scanning works on mobile', async ({ page }) => {
test.skip(!process.env.MOBILE_TEST, 'Mobile-only test');
// Test implementation
});
```
## 7. Error Handling
### 7.1 Global Error Handler
```typescript
function setupGlobalErrorHandler(app: VueApp) {
app.config.errorHandler = (err, instance, info) => {
logger.error("[App Error]", {
error: err,
info,
component: instance?.$options.name
});
};
}
```
### 7.2 Platform-Specific Error Handling
```typescript
// API error handling for Capacitor
if (process.env.VITE_PLATFORM === 'capacitor') {
logger.error(`[Capacitor API Error] ${endpoint}:`, {
message: error.message,
status: error.response?.status
});
}
```
## 8. Best Practices
### 8.1 Code Organization
- Use platform-specific directories for unique implementations
- Share common code through service interfaces
- Implement feature detection before using platform capabilities
- Keep platform-specific code isolated in dedicated directories
- Use TypeScript interfaces for cross-platform compatibility
### 8.2 Platform Detection
```typescript
const platformService = PlatformServiceFactory.getInstance();
const capabilities = platformService.getCapabilities();
if (capabilities.hasCamera) {
// Implement camera features
}
```
### 8.3 Feature Implementation
1. Define platform-agnostic interface
2. Create platform-specific implementations
3. Use factory pattern for instantiation
4. Implement graceful fallbacks
5. Add comprehensive error handling
6. Use dependency injection for better testability
## 9. Dependency Management
### 9.1 Platform-Specific Dependencies
```json
{
"dependencies": {
"@capacitor/core": "^6.2.0",
"electron": "^33.2.1",
"vue": "^3.4.0"
}
}
```
### 9.2 Conditional Loading
```typescript
if (process.env.VITE_PLATFORM === 'capacitor') {
await import('@capacitor/core');
}
```
## 10. Security Considerations
### 10.1 Permission Handling
```typescript
async checkPermissions(): Promise<boolean> {
if (platformService.isCapacitor()) {
return await checkNativePermissions();
}
return await checkWebPermissions();
}
```
### 10.2 Data Storage
- Use secure storage mechanisms for sensitive data
- Implement proper encryption for stored data
- Follow platform-specific security guidelines
- Regular security audits and updates
This document should be updated as new features are added or platform-specific implementations change. Regular reviews ensure it remains current with the codebase.

View File

@@ -1,32 +0,0 @@
---
alwaysApply: true
---
# Asset Configuration Directive
*Scope: Assets Only (icons, splashes, image pipelines) — not overall build orchestration*
## Intent
- Version **asset configuration files** (optionally dev-time generated).
- **Do not** version platform asset outputs (Android/iOS/Electron); generate them **at build-time** with standard tools.
- Keep existing per-platform build scripts unchanged.
## Source of Truth
- **Preferred (Capacitor default):** `resources/` as the single master source.
- **Alternative:** `assets/` is acceptable **only** if `capacitor-assets` is explicitly configured to read from it.
- **Never** maintain both `resources/` and `assets/` as parallel sources. Migrate and delete the redundant folder.
## Config Files
- Live under: `config/assets/` (committed).
- Examples:
- `config/assets/capacitor-assets.config.json` (or the path the tool expects)
- `config/assets/android.assets.json`
- `config/assets/ios.assets.json`
- `config/assets/common.assets.yaml` (optional shared layer)
- **Dev-time generation allowed** for these configs; **build-time generation is forbidden**.
## Build-Time Behavior
- Build generates platform assets (not configs) using the standard chain:
```bash
npm run build:capacitor # web build via Vite (.mts)
npx cap sync
npx capacitor-assets generate # produces platform assets; not committed
# then platform-specific build steps

View File

@@ -1,110 +0,0 @@
```json
{
"coaching_level": "standard",
"socratic_max_questions": 7,
"verbosity": "normal",
"timebox_minutes": null,
"format_enforcement": "strict"
}
```
# Base Context — Human Competence First
## Purpose
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
than replacing it — outputs should be designed to **facilitate human discussion,
decision-making, and creativity**, not to atomize tasks into isolated, purely
machine-driven steps.
## Principles
1) Competence over convenience: finish the task *and* leave the human more
capable next time.
2) Mentorship, not lectures: be concise, concrete, and immediately applicable.
3) Transparency: show assumptions, limits, and uncertainty; cite when non-obvious.
4) Optional scaffolding: include small, skimmable learning hooks that do not
bloat output.
5) Time respect: default to **lean output**; offer opt-in depth via toggles.
6) Psychological safety: encourage, never condescend; no medical/clinical advice.
No censorship!
7) Reusability: structure outputs so they can be saved, searched, reused, and repurposed.
8) **Collaborative Bias**: Favor solutions that invite human review, discussion,
and iteration. When in doubt, ask "Who should this be shown to?" or "Which human
input would improve this?"
## Toggle Definitions
### coaching_level
Determines the depth of learning support: `light` (short hooks), `standard`
(balanced), `deep` (detailed).
### socratic_max_questions
The number of clarifying questions the model may ask before proceeding.
If >0, questions should be targeted, minimal, and followed by reasonable assumptions if unanswered.
### verbosity
'terse' (just a sentence), `concise` (minimum commentary), `normal` (balanced explanation), or other project-defined levels.
### timebox_minutes
*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.
Behavior when set:
1. **Prioritize Core Output** — Deliver the minimum viable solution or result first.
2. **Limit Commentary** — Competence Hooks and Collaboration Hooks must be shorter than normal.
3. **Signal Skipped Depth** — Omitted details should be listed under *Deferred for depth*.
4. **Order by Value** — Start with blocking or high-value items, then proceed to nice-to-haves if budget allows.
If `null`, there is no timebox — the model can produce full-depth responses.
### format_enforcement
`strict` (reject outputs with format drift) or `relaxed` (minor deviations acceptable).
## Modes (select or combine)
- **Doer**: produce the artifact fast, minimal commentary.
- **Mentor**: add short "why/how" notes + next-step pointers.
- **Socratic**: ask up to N targeted questions when requirements are ambiguous.
- **Pair-Programmer/Pair-Writer**: explain tradeoffs as you implement.
- **Facilitator**: structure output to be reviewable, commentable, and ready for group discussion.
Default: Doer + short Mentor notes.
## Competence & Collaboration Levers (keep lightweight)
- "Why this works" (≤3 bullets)
- "Common pitfalls" (≤3 bullets)
- "Next skill unlock" (1 tiny action or reading)
- "Teach-back" (1 sentence prompt the human can answer to self-check)
- "Discussion prompts" (≤2 short questions for peers/stakeholders)
## Output Contract (apply to every deliverable)
- Clear **Objective** (1 line)
- **Result** (artifact/code/answer)
- **Use/Run** (how to apply/test)
- **Competence Hooks** (the 4 learning levers above, kept terse)
- **Collaboration Hooks** (discussion prompts or group review steps)
- **Assumptions & Limits**
- **References** (if used; links or titles)
## Do-Not
- No filler, hedging, or moralizing.
- No medical/mental-health advice; keep "healthy habits" to general work practices.
- No invented facts; mark uncertainty plainly.
- No censorship.
- Avoid outputs that bypass human review when such review is valuable.
## Related Rulesets
- **software_development.mdc**: For software-specific development practices
- **research_diagnostic.mdc**: For investigation and research workflows
## Self-Check (model, before responding)
- [ ] 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.
- [ ] Toggles respected; verbosity remains concise.
- [ ] Uncertainties/assumptions surfaced.
- [ ] No disallowed content.
- [ ] Uncertainties/assumptions surfaced.
- [ ] No disallowed content.

View File

@@ -1,9 +0,0 @@
---
globs: **/src/**/*
alwaysApply: false
---
✅ 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

View File

@@ -1,108 +0,0 @@
---
globs: **/src/**/*,**/scripts/**/*,**/electron/**/*
alwaysApply: false
---
```json
{
"coaching_level": "light",
"socratic_max_questions": 7,
"verbosity": "concise",
"timebox_minutes": null,
"format_enforcement": "strict"
}
```
# TypeScript Type Safety Guidelines
**Author**: Matthew Raymer
**Date**: 2025-08-16
**Status**: 🎯 **ACTIVE**
## Overview
Practical rules to keep TypeScript strict and predictable. Minimize exceptions.
## Core Rules
1. **No `any`**
- Use explicit types. If unknown, use `unknown` and **narrow** via guards.
2. **Error handling uses guards**
- Reuse guards from `src/interfaces/**` (e.g., `isDatabaseError`, `isApiError`).
- Catch with `unknown`; never cast to `any`.
3. **Dynamic property access is typesafe**
- Use `keyof` + `in` checks:
```ts
obj[k as keyof typeof obj]
```
- Avoid `(obj as any)[k]`.
## Minimal Special Cases (document in PR when used)
- **Vue refs / instances**: Use `ComponentPublicInstance` or specific component
types for dynamic refs.
- **3rdparty libs without types**: Narrow immediately to a **known interface**;
do not leave `any` hanging.
## Patterns (short)
### Database errors
```ts
try { await this.$addContact(contact); }
catch (e: unknown) {
if (isDatabaseError(e) && e.message.includes("Key already exists")) {
/* handle duplicate */
}
}
```
### API errors
```ts
try { await apiCall(); }
catch (e: unknown) {
if (isApiError(e)) {
const msg = e.response?.data?.error?.message;
}
}
```
### Dynamic keys
```ts
const keys = Object.keys(newSettings).filter(
k => k in newSettings && newSettings[k as keyof typeof newSettings] !== undefined
);
```
## Checklists
**Before commit**
- [ ] No `any` (except documented, justified cases)
- [ ] Errors handled via guards
- [ ] Dynamic access uses `keyof`/`in`
- [ ] Imports point to correct interfaces/types
**Code review**
- [ ] Hunt hidden `as any`
- [ ] Guardbased error paths verified
- [ ] Dynamic ops are typesafe
- [ ] Prefer existing types over reinventing
## Tools
- `npm run lint-fix` — lint & autofix
- `npm run type-check` — strict type compilation (CI + prerelease)
- IDE: enable strict TS, ESLint/TS ESLint, Volar (Vue 3)
## References
- TS Handbook — https://www.typescriptlang.org/docs/
- TSESLint — https://typescript-eslint.io/rules/
- Vue 3 + TS — https://vuejs.org/guide/typescript/

View File

@@ -0,0 +1,35 @@
---
description: rules used while developing
globs:
alwaysApply: true
---
✅ 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
✅ do not add or commit for the user; let him control that process
always preview changes and commit message to use and allow me to copy and paste
✅ Preferred Commit Message Format
Short summary in the first line (concise and high-level).
Avoid long commit bodies unless truly necessary.
✅ Valued Content in Commit Messages
Specific fixes or features.
Symptoms or problems that were fixed.
Notes about tests passing or TS/linting errors being resolved (briefly).
❌ Avoid in Commit Messages
Vague terms: “improved”, “enhanced”, “better” — especially from AI.
Minor changes: small doc tweaks, one-liners, cleanup, or lint fixes.
Redundant blurbs: repeated across files or too generic.
Multiple overlapping purposes in a single commit — prefer narrow, focused commits.
Long explanations of what can be deduced from good in-line code comments.
Guiding Principle
Let code and inline documentation speak for themselves. Use commits to highlight what isn't obvious from reading the code.

View File

@@ -1,14 +0,0 @@
---
alwaysApply: true
---
# Directive for Documentation Generation
1. Produce a **small, focused set of documents** rather than an overwhelming volume.
2. Ensure the content is **maintainable and worth preserving**, so that humans
are motivated to keep it up to date.
3. Prioritize **educational value**: the documents must clearly explain the
workings of the system.
4. Avoid **shallow, generic, or filler explanations** often found in
AI-generated documentation.
5. Aim for **clarity, depth, and usefulness**, so readers gain genuine understanding.
6. Always check the local system date to determine current date.

View File

@@ -1,76 +0,0 @@
# Investigation Report Example
## Investigation — Registration Dialog Test Flakiness
## Objective
Identify root cause of flaky tests related to registration dialogs in contact import scenarios.
## System Map
- User action → ContactInputForm → ContactsView.addContact() → handleRegistrationPrompt()
- setTimeout(1000ms) → Modal dialog → User response → Registration API call
- Test execution → Wait for dialog → Assert dialog content → Click response button
## Findings (Evidence)
- **1-second timeout causes flakiness** — evidence: `src/views/ContactsView.vue:971-1000`; setTimeout(..., 1000) in handleRegistrationPrompt()
- **Import flow bypasses dialogs** — evidence: `src/views/ContactImportView.vue:500-520`; importContacts() calls $insertContact() directly, no handleRegistrationPrompt()
- **Dialog only appears in direct add flow** — evidence: `src/views/ContactsView.vue:774-800`; addContact() calls handleRegistrationPrompt() after database insert
## Hypotheses & Failure Modes
- H1: 1-second timeout makes dialog appearance unpredictable; would fail when tests run faster than 1000ms
- H2: Test environment timing differs from development; watch for CI vs local test differences
## Corrections
- Updated: "Multiple dialogs interfere with imports" → "Import flow never triggers dialogs - they only appear in direct contact addition"
- Updated: "Complex batch registration needed" → "Simple timeout removal and test mode flag sufficient"
## Diagnostics (Next Checks)
- [ ] Repro on CI environment vs local
- [ ] Measure actual dialog appearance timing
- [ ] Test with setTimeout removed
- [ ] Verify import flow doesn't call handleRegistrationPrompt
## Risks & Scope
- Impacted: Contact addition tests, registration workflow tests; Data: None; Users: Test suite reliability
## Decision / Next Steps
- Owner: Development Team; By: 2025-01-28
- Action: Remove 1-second timeout + add test mode flag; Exit criteria: Tests pass consistently
## References
- `src/views/ContactsView.vue:971-1000`
- `src/views/ContactImportView.vue:500-520`
- `src/views/ContactsView.vue:774-800`
## Competence Hooks
- Why this works: Code path tracing revealed separate execution flows, evidence disproved initial assumptions
- Common pitfalls: Assuming related functionality without tracing execution paths, over-engineering solutions to imaginary problems
- Next skill: Learn to trace code execution before proposing architectural changes
- Teach-back: "What evidence shows that contact imports bypass registration dialogs?"
---
## Key Learning Points
### Evidence-First Approach
This investigation demonstrates the importance of:
1. **Tracing actual code execution** rather than making assumptions
2. **Citing specific evidence** with file:line references
3. **Validating problem scope** before proposing solutions
4. **Considering simpler alternatives** before complex architectural changes
### Code Path Tracing Value
By tracing the execution paths, we discovered:
- Import flow and direct add flow are completely separate
- The "multiple dialog interference" problem didn't exist
- A simple timeout removal would solve the actual issue
### Prevention of Over-Engineering
The investigation prevented:
- Unnecessary database schema changes
- Complex batch registration systems
- Migration scripts for non-existent problems
- Architectural changes based on assumptions
description:
globs:
alwaysApply: false
---

View File

@@ -1,5 +1,6 @@
---
globs: **/databaseUtil.ts,**/AccountViewView.vue,**/ContactsView.vue,**/DatabaseMigration.vue,**/NewIdentifierView.vue
alwaysApply: false
description:
globs:
alwaysApply: true
---
All references in the codebase to Dexie apply only to migration from IndexedDb to Sqlite and will be deprecated in future versions.

View File

@@ -312,21 +312,3 @@ Description of current situation or problem.
**Last Updated**: 2025-07-09
**Version**: 1.0
**Maintainer**: Matthew Raymer
### Heading Uniqueness
- **Rule**: No duplicate heading content at the same level
- **Scope**: Within a single document
- **Rationale**: Maintains clear document structure and navigation
- **Example**:
```markdown
## Features ✅
### Authentication
### Authorization
## Features ❌ (Duplicate heading)
### Security
### Performance
```

View File

@@ -1,170 +0,0 @@
---
description: Use this workflow when doing **pre-implementation research, defect investigations with uncertain repros, or clarifying system architecture and behaviors**.
alwaysApply: false
---
```json
{
"coaching_level": "light",
"socratic_max_questions": 2,
"verbosity": "concise",
"timebox_minutes": null,
"format_enforcement": "strict"
}
```
# Research & Diagnostic Workflow (R&D)
## Purpose
Provide a **repeatable, evidence-first** workflow to investigate features and
defects **before coding**. Outputs are concise reports, hypotheses, and next
steps—**not** code changes.
## When to Use
- Pre-implementation research for new features
- Defect investigations (repros uncertain, user-specific failures)
- Architecture/behavior clarifications (e.g., auth flows, merges, migrations)
---
## Enhanced with Software Development Ruleset
When investigating software issues, also apply:
- **Code Path Tracing**: Required for technical investigations
- **Evidence Validation**: Ensure claims are code-backed
- **Solution Complexity Assessment**: Justify architectural changes
---
## Output Contract (strict)
1) **Objective** — 12 lines
2) **System Map (if helpful)** — short diagram or bullet flow (≤8 bullets)
3) **Findings (Evidence-linked)** — bullets; each with file/function refs
4) **Hypotheses & Failure Modes** — short list, each testable
5) **Corrections** — explicit deltas from earlier assumptions (if any)
6) **Diagnostics** — what to check next (logs, DB, env, repro steps)
7) **Risks & Scope** — what could break; affected components
8) **Decision/Next Steps** — what we'll do, who's involved, by when
9) **References** — code paths, ADRs, docs
10) **Competence & Collaboration Hooks** — brief, skimmable
> Keep total length lean. Prefer links and bullets over prose.
---
## Quickstart Template
Copy/paste and fill:
```md
# Investigation — <short title>
## Objective
<one or two lines>
## System Map
- <module> → <function> → <downstream>
- <data path> → <db table> → <api>
## Findings (Evidence)
- <claim> — evidence: `src/path/file.ts:function` (lines XY); log snippet/trace id
- <claim> — evidence: `...`
## Hypotheses & Failure Modes
- H1: <hypothesis>; would fail when <condition>
- H2: <hypothesis>; watch for <signal>
## Corrections
- Updated: <old statement> → <new statement with evidence>
## Diagnostics (Next Checks)
- [ ] Repro on <platform/version>
- [ ] Inspect <table/store> for <record>
- [ ] Capture <log/trace>
## Risks & Scope
- Impacted: <areas/components>; Data: <tables/keys>; Users: <segments>
## Decision / Next Steps
- Owner: <name>; By: <date> (YYYY-MM-DD)
- Action: <spike/bugfix/ADR>; Exit criteria: <binary checks>
## References
- `src/...`
- ADR: `docs/adr/xxxx-yy-zz-something.md`
- Design: `docs/...`
## Competence Hooks
- Why this works: <≤3 bullets>
- Common pitfalls: <≤3 bullets>
- Next skill: <≤1 item>
- Teach-back: "<one question>"
```
---
## Evidence Quality Bar
- **Cite the source** (file:func, line range if possible).
- **Prefer primary evidence** (code, logs) over inference.
- **Disambiguate platform** (Web/Capacitor/Electron) and **state** (migration, auth).
- **Note uncertainty** explicitly.
---
## Code Path Tracing (Required for Software Investigations)
Before proposing solutions, trace the actual execution path:
- [ ] **Entry Points**: Identify where the flow begins (user action, API call, etc.)
- [ ] **Component Flow**: Map which components/methods are involved
- [ ] **Data Path**: Track how data moves through the system
- [ ] **Exit Points**: Confirm where the flow ends and what results
- [ ] **Evidence Collection**: Gather specific code citations for each step
---
## Collaboration Hooks
- **Syncs:** 1015m with QA/Security/Platform owners for high-risk areas.
- **ADR:** Record major decisions; link here.
- **Review:** Share repro + diagnostics checklist in PR/issue.
---
## Integration with Other Rulesets
### With software_development.mdc
- **Enhanced Evidence Validation**: Use code path tracing for technical investigations
- **Architecture Assessment**: Apply complexity justification to proposed solutions
- **Impact Analysis**: Assess effects on existing systems before recommendations
### With base_context.mdc
- **Competence Building**: Focus on technical investigation skills
- **Collaboration**: Structure outputs for team review and discussion
---
## Self-Check (model, before responding)
- [ ] Output matches the **Output Contract** sections.
- [ ] Each claim has **evidence** or **uncertainty** is flagged.
- [ ] Hypotheses are testable; diagnostics are actionable.
- [ ] Competence + collaboration hooks present (≤120 words total).
- [ ] Respect toggles; keep it concise.
- [ ] **Code path traced** (for software investigations).
- [ ] **Evidence validated** against actual code execution.
---
## Optional Globs (examples)
> Uncomment `globs` in the header if you want auto-attach behavior.
- `src/platforms/**`, `src/services/**` — attach during service/feature investigations
- `docs/adr/**` — attach when editing ADRs
## Referenced Files
- Consider including templates as context: `@adr_template.mdc`, `@investigation_report_example.mdc`

View File

@@ -1,178 +0,0 @@
---
alwaysApply: true
---
# Software Development Ruleset
## Purpose
Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing.
## Core Principles
### 1. Evidence-First Development
- **Code Citations Required**: Always cite specific file:line references when making claims
- **Execution Path Tracing**: Trace actual code execution before proposing architectural changes
- **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based"
### 2. Code Review Standards
- **Trace Before Proposing**: Always trace execution paths before suggesting changes
- **Evidence Over Inference**: Prefer code citations over logical deductions
- **Scope Validation**: Confirm the actual scope of problems before proposing solutions
### 3. Problem-Solution Validation
- **Problem Scope**: Does the solution address the actual problem?
- **Evidence Alignment**: Does the solution match the evidence?
- **Complexity Justification**: Is added complexity justified by real needs?
- **Alternative Analysis**: What simpler solutions were considered?
## Required Workflows
### Before Proposing Changes
- [ ] **Code Path Tracing**: Map execution flow from entry to exit
- [ ] **Evidence Collection**: Gather specific code citations and logs
- [ ] **Assumption Surfacing**: Identify what's proven vs. inferred
- [ ] **Scope Validation**: Confirm the actual extent of the problem
### During Solution Design
- [ ] **Evidence Alignment**: Ensure solution addresses proven problems
- [ ] **Complexity Assessment**: Justify any added complexity
- [ ] **Alternative Evaluation**: Consider simpler approaches first
- [ ] **Impact Analysis**: Assess effects on existing systems
## Software-Specific Competence Hooks
### Evidence Validation
- **"What code path proves this claim?"**
- **"How does data actually flow through the system?"**
- **"What am I assuming vs. what can I prove?"**
### Code Tracing
- **"What's the execution path from user action to system response?"**
- **"Which components actually interact in this scenario?"**
- **"Where does the data originate and where does it end up?"**
### Architecture Decisions
- **"What evidence shows this change is necessary?"**
- **"What simpler solution could achieve the same goal?"**
- **"How does this change affect the existing system architecture?"**
## Integration with Other Rulesets
### With base_context.mdc
- Inherits generic competence principles
- Adds software-specific evidence requirements
- Maintains collaboration and learning focus
### With research_diagnostic.mdc
- Enhances investigation with code path tracing
- Adds evidence validation to diagnostic workflow
- Strengthens problem identification accuracy
## Usage Guidelines
### When to Use This Ruleset
- Code reviews and architectural decisions
- Bug investigation and debugging
- Performance optimization
- Feature implementation planning
- Testing strategy development
### When to Combine with Others
- **base_context + software_development**: General development tasks
- **research_diagnostic + software_development**: Technical investigations
- **All three**: Complex architectural decisions or major refactoring
## Self-Check (model, before responding)
- [ ] Code path traced and documented
- [ ] Evidence cited with specific file:line references
- [ ] Assumptions clearly flagged as proven vs. inferred
- [ ] Solution complexity justified by evidence
- [ ] Simpler alternatives considered and documented
- [ ] Impact on existing systems assessed
# Software Development Ruleset
## Purpose
Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing.
## Core Principles
### 1. Evidence-First Development
- **Code Citations Required**: Always cite specific file:line references when making claims
- **Execution Path Tracing**: Trace actual code execution before proposing architectural changes
- **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based"
### 2. Code Review Standards
- **Trace Before Proposing**: Always trace execution paths before suggesting changes
- **Evidence Over Inference**: Prefer code citations over logical deductions
- **Scope Validation**: Confirm the actual scope of problems before proposing solutions
### 3. Problem-Solution Validation
- **Problem Scope**: Does the solution address the actual problem?
- **Evidence Alignment**: Does the solution match the evidence?
- **Complexity Justification**: Is added complexity justified by real needs?
- **Alternative Analysis**: What simpler solutions were considered?
## Required Workflows
### Before Proposing Changes
- [ ] **Code Path Tracing**: Map execution flow from entry to exit
- [ ] **Evidence Collection**: Gather specific code citations and logs
- [ ] **Assumption Surfacing**: Identify what's proven vs. inferred
- [ ] **Scope Validation**: Confirm the actual extent of the problem
### During Solution Design
- [ ] **Evidence Alignment**: Ensure solution addresses proven problems
- [ ] **Complexity Assessment**: Justify any added complexity
- [ ] **Alternative Evaluation**: Consider simpler approaches first
- [ ] **Impact Analysis**: Assess effects on existing systems
## Software-Specific Competence Hooks
### Evidence Validation
- **"What code path proves this claim?"**
- **"How does data actually flow through the system?"**
- **"What am I assuming vs. what can I prove?"**
### Code Tracing
- **"What's the execution path from user action to system response?"**
- **"Which components actually interact in this scenario?"**
- **"Where does the data originate and where does it end up?"**
### Architecture Decisions
- **"What evidence shows this change is necessary?"**
- **"What simpler solution could achieve the same goal?"**
- **"How does this change affect the existing system architecture?"**
## Integration with Other Rulesets
### With base_context.mdc
- Inherits generic competence principles
- Adds software-specific evidence requirements
- Maintains collaboration and learning focus
### With research_diagnostic.mdc
- Enhances investigation with code path tracing
- Adds evidence validation to diagnostic workflow
- Strengthens problem identification accuracy
## Usage Guidelines
### When to Use This Ruleset
- Code reviews and architectural decisions
- Bug investigation and debugging
- Performance optimization
- Feature implementation planning
- Testing strategy development
### When to Combine with Others
- **base_context + software_development**: General development tasks
- **research_diagnostic + software_development**: Technical investigations
- **All three**: Complex architectural decisions or major refactoring
## Self-Check (model, before responding)
- [ ] Code path traced and documented
- [ ] Evidence cited with specific file:line references
- [ ] Assumptions clearly flagged as proven vs. inferred
- [ ] Solution complexity justified by evidence
- [ ] Simpler alternatives considered and documented
- [ ] Impact on existing systems assessed

View File

@@ -1,96 +1,70 @@
---
description:
globs:
description:
globs:
alwaysApply: true
---
---
description:
globs:
alwaysApply: true
---
# Time Safari Context
## Project Overview
Time Safari is an application designed to foster community building through gifts,
gratitude, and collaborative projects. The app should make it extremely easy and
intuitive for users of any age and capability to recognize contributions, build
trust networks, and organize collective action. It is built on services that
preserve privacy and data sovereignty.
Time Safari is an application designed to foster community building through gifts, gratitude, and collaborative projects. The app should make it extremely easy and intuitive for users of any age and capability to recognize contributions, build trust networks, and organize collective action. It is built on services that preserve privacy and data sovereignty.
The ultimate goals of Time Safari are two-fold:
1. **Connect** Make it easy, rewarding, and non-threatening for people to
connect with others who have similar interests, and to initiate activities
together. This helps people accomplish and learn from other individuals in
less-structured environments; moreover, it helps them discover who they want
to continue to support and with whom they want to maintain relationships.
1. **Connect** Make it easy, rewarding, and non-threatening for people to connect with others who have similar interests, and to initiate activities together. This helps people accomplish and learn from other individuals in less-structured environments; moreover, it helps them discover who they want to continue to support and with whom they want to maintain relationships.
2. **Reveal** Widely advertise the great support and rewards that are being
given and accepted freely, especially non-monetary ones. Using visuals and text,
display the kind of impact that gifts are making in the lives of others. Also
show useful and engaging reports of project statistics and personal accomplishments.
2. **Reveal** Widely advertise the great support and rewards that are being given and accepted freely, especially non-monetary ones. Using visuals and text, display the kind of impact that gifts are making in the lives of others. Also show useful and engaging reports of project statistics and personal accomplishments.
## Core Approaches
Time Safari should help everyday users build meaningful connections and organize
collective efforts by:
Time Safari should help everyday users build meaningful connections and organize collective efforts by:
1. **Recognizing Contributions**: Creating permanent, verifiable records of gifts
and contributions people give to each other and their communities.
1. **Recognizing Contributions**: Creating permanent, verifiable records of gifts and contributions people give to each other and their communities.
2. **Facilitating Collaboration**: Making it ridiculously easy for people to ask
for or propose help on projects and interests that matter to them.
2. **Facilitating Collaboration**: Making it ridiculously easy for people to ask for or propose help on projects and interests that matter to them.
3. **Building Trust Networks**: Enabling users to maintain their network and activity
visibility. Developing reputation through verified contributions and references,
which can be selectively shown to others outside the network.
3. **Building Trust Networks**: Enabling users to maintain their network and activity visibility. Developing reputation through verified contributions and references, which can be selectively shown to others outside the network.
4. **Preserving Privacy**: Ensuring personal identifiers are only shared with
explicitly authorized contacts, allowing private individuals including children
to participate safely.
4. **Preserving Privacy**: Ensuring personal identifiers are only shared with explicitly authorized contacts, allowing private individuals including children to participate safely.
5. **Engaging Content**: Displaying people's records in compelling stories, and
highlighting those projects that are lifting people's lives long-term, both in
physical support and in emotional-spiritual-creative thriving.
5. **Engaging Content**: Displaying people's records in compelling stories, and highlighting those projects that are lifting people's lives long-term, both in physical support and in emotional-spiritual-creative thriving.
## Technical Foundation
This application is built on a privacy-preserving claims architecture (via
endorser.ch) with these key characteristics:
This application is built on a privacy-preserving claims architecture (via endorser.ch) with these key characteristics:
- **Decentralized Identifiers (DIDs)**: User identities are based on public/private
key pairs stored on their devices
- **Cryptographic Verification**: All claims and confirmations are
cryptographically signed
- **User-Controlled Visibility**: Users explicitly control who can see their
identifiers and data
- **Merkle-Chained Claims**: Claims are cryptographically chained for verification
and integrity
- **Native and Web App**: Works on Capacitor (iOS, Android), Desktop (Electron
and CEFPython), and web browsers
- **Decentralized Identifiers (DIDs)**: User identities are based on public/private key pairs stored on their devices
- **Cryptographic Verification**: All claims and confirmations are cryptographically signed
- **User-Controlled Visibility**: Users explicitly control who can see their identifiers and data
- **Merkle-Chained Claims**: Claims are cryptographically chained for verification and integrity
- **Native and Web App**: Works on Capacitor (iOS, Android), Desktop (Electron and CEFPython), and web browsers
## User Journey
The typical progression of usage follows these stages:
1. **Gratitude & Recognition**: Users begin by expressing and recording gratitude
for gifts received, building a foundation of acknowledgment.
1. **Gratitude & Recognition**: Users begin by expressing and recording gratitude for gifts received, building a foundation of acknowledgment.
2. **Project Proposals**: Users propose projects and ideas, reaching out to connect
with others who share similar interests.
2. **Project Proposals**: Users propose projects and ideas, reaching out to connect with others who share similar interests.
3. **Action Triggers**: Offers of help serve as triggers and motivations to execute
proposed projects, moving from ideas to action.
3. **Action Triggers**: Offers of help serve as triggers and motivations to execute proposed projects, moving from ideas to action.
## Context for LLM Development
When developing new functionality for Time Safari, consider these design principles:
1. **Accessibility First**: Features should be usable by non-technical users with
minimal learning curve.
1. **Accessibility First**: Features should be usable by non-technical users with minimal learning curve.
2. **Privacy by Design**: All features must respect user privacy and data sovereignty.
3. **Progressive Enhancement**: Core functionality should work across all devices,
with richer experiences where supported.
3. **Progressive Enhancement**: Core functionality should work across all devices, with richer experiences where supported.
4. **Voluntary Collaboration**: The system should enable but never coerce participation.
@@ -98,40 +72,31 @@ with richer experiences where supported.
6. **Network Effects**: Consider how features scale as more users join the platform.
7. **Low Resource Requirements**: The system should be lightweight enough to run
on inexpensive devices users already own.
7. **Low Resource Requirements**: The system should be lightweight enough to run on inexpensive devices users already own.
## Use Cases to Support
LLM development should focus on enhancing these key use cases:
1. **Community Building**: Tools that help people find others with shared
interests and values.
1. **Community Building**: Tools that help people find others with shared interests and values.
2. **Project Coordination**: Features that make it easy to propose collaborative
projects and to submit suggestions and offers to existing ones.
2. **Project Coordination**: Features that make it easy to propose collaborative projects and to submit suggestions and offers to existing ones.
3. **Reputation Building**: Methods for users to showcase their contributions
and reliability, in contexts where they explicitly reveal that information.
3. **Reputation Building**: Methods for users to showcase their contributions and reliability, in contexts where they explicitly reveal that information.
4. **Governance Experimentation**: Features that facilitate decision-making and
collective governance.
4. **Governance Experimentation**: Features that facilitate decision-making and collective governance.
## Constraints
When developing new features, be mindful of these constraints:
1. **Privacy Preservation**: User identifiers must remain private except when
explicitly shared.
1. **Privacy Preservation**: User identifiers must remain private except when explicitly shared.
2. **Platform Limitations**: Features must work within the constraints of the target
app platforms, while aiming to leverage the best platform technology available.
2. **Platform Limitations**: Features must work within the constraints of the target app platforms, while aiming to leverage the best platform technology available.
3. **Endorser API Limitations**: Backend features are constrained by the endorser.ch
API capabilities.
3. **Endorser API Limitations**: Backend features are constrained by the endorser.ch API capabilities.
4. **Performance on Low-End Devices**: The application should remain performant
on older/simpler devices.
4. **Performance on Low-End Devices**: The application should remain performant on older/simpler devices.
5. **Offline-First When Possible**: Key functionality should work offline when feasible.
@@ -151,14 +116,12 @@ on older/simpler devices.
## Project Architecture
- The application must work on web browser, PWA (Progressive Web Application),
desktop via Electron, and mobile via Capacitor
- The application must work on web browser, PWA (Progressive Web Application), desktop via Electron, and mobile via Capacitor
- Building for each platform is managed via Vite
## Core Development Principles
### DRY development
- **Code Reuse**
- Extract common functionality into utility functions
- Create reusable components for UI patterns
@@ -214,24 +177,14 @@ on older/simpler devices.
- Use shared test configurations
- Create reusable test helpers
- Implement consistent test patterns
- F.I.R.S.T. (for Unit Tests)
F Fast
I Independent
R Repeatable
S Self-validating
T Timely
### SOLID Principles
- **Single Responsibility**: Each class/component should have only one reason to
change
- **Single Responsibility**: Each class/component should have only one reason to change
- Components should focus on one specific feature (e.g., QR scanning, DID management)
- Services should handle one type of functionality (e.g., platform services,
crypto services)
- Services should handle one type of functionality (e.g., platform services, crypto services)
- Utilities should provide focused helper functions
- **Open/Closed**: Software entities should be open for extension but closed for
modification
- **Open/Closed**: Software entities should be open for extension but closed for modification
- Use interfaces for service definitions
- Implement plugin architecture for platform-specific features
- Allow component behavior extension through props and events
@@ -252,7 +205,6 @@ on older/simpler devices.
- Implement factory patterns for component creation
### Law of Demeter
- Components should only communicate with immediate dependencies
- Avoid chaining method calls (e.g., `this.service.getUser().getProfile().getName()`)
- Use mediator patterns for complex component interactions
@@ -260,7 +212,6 @@ on older/simpler devices.
- Keep component communication through defined events and props
### Composition over Inheritance
- Prefer building components through composition
- Use mixins for shared functionality
- Implement feature toggles through props
@@ -268,7 +219,6 @@ on older/simpler devices.
- Use service composition for complex features
### Interface Segregation
- Define clear interfaces for services
- Keep component APIs minimal and focused
- Split large interfaces into smaller, specific ones
@@ -276,7 +226,6 @@ on older/simpler devices.
- Implement role-based interfaces for different use cases
### Fail Fast
- Validate inputs early in the process
- Use TypeScript strict mode
- Implement comprehensive error handling
@@ -284,7 +233,6 @@ on older/simpler devices.
- Use assertions for development-time validation
### Principle of Least Astonishment
- Follow Vue.js conventions consistently
- Use familiar naming patterns
- Implement predictable component behaviors
@@ -292,7 +240,6 @@ on older/simpler devices.
- Keep UI interactions intuitive
### Information Hiding
- Encapsulate implementation details
- Use private class members
- Implement proper access modifiers
@@ -300,7 +247,6 @@ on older/simpler devices.
- Use TypeScript's access modifiers effectively
### Single Source of Truth
- Use Pinia for state management
- Maintain one source for user data
- Centralize configuration management
@@ -308,9 +254,23 @@ on older/simpler devices.
- Implement proper state synchronization
### Principle of Least Privilege
- Implement proper access control
- Use minimal required permissions
- Follow privacy-by-design principles
- Restrict component access to necessary data
- Implement proper authentication/authorization
### Continuous Integration/Continuous Deployment (CI/CD)
- Automated testing on every commit
- Consistent build process across platforms
- Automated deployment pipelines
- Quality gates for code merging
- Environment-specific configurations
This expanded documentation provides:
1. Clear principles for development
2. Practical implementation guidelines
3. Real-world examples
4. TypeScript integration
5. Best practices for Time Safari

View File

@@ -1,122 +0,0 @@
---
alwaysApply: true
---
# Directive: Peaceful Co-Existence with Developers
## 1) Version-Control Ownership
* **MUST NOT** run `git add`, `git commit`, or any write action.
* **MUST** leave staging/committing to the developer.
## 2) Source of Truth for Commit Text
* **MUST** derive messages **only** from:
* files **staged** for commit (primary), and
* files **awaiting staging** (context).
* **MUST** use the **diffs** to inform content.
* **MUST NOT** invent changes or imply work not present in diffs.
## 3) Mandatory Preview Flow
* **ALWAYS** present, before any real commit:
* file list + brief per-file notes,
* a **draft commit message** (copy-paste ready),
* nothing auto-applied.
---
# Commit Message Format (Normative)
## A. Subject Line (required)
```
<type>(<scope>)<!>: <summary>
```
* **type** (lowercase, Conventional Commits): `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
* **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
* **!**: include when a breaking change is introduced
* **summary**: imperative mood, ≤ 72 chars, no trailing period
**Examples**
* `fix(api): handle null token in refresh path`
* `feat(ui/login)!: require OTP after 3 failed attempts`
## B. Body (optional, when it adds non-obvious value)
* One blank line after subject.
* Wrap at \~72 chars.
* Explain **what** and **why**, not line-by-line “how”.
* Include brief notes like tests passing or TS/lint issues resolved **only if material**.
**Body checklist**
* [ ] Problem/symptom being addressed
* [ ] High-level approach or rationale
* [ ] Risks, tradeoffs, or follow-ups (if any)
## C. Footer (optional)
* Issue refs: `Closes #123`, `Refs #456`
* Breaking change (alternative to `!`):
`BREAKING CHANGE: <impact + migration note>`
* Authors: `Co-authored-by: Name <email>`
* Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
---
## Content Guidance
### Include (when relevant)
* Specific fixes/features delivered
* Symptoms/problems fixed
* Brief note that tests passed or TS/lint errors resolved
### Avoid
* Vague: *improved, enhanced, better*
* Trivialities: tiny docs, one-liners, pure lint cleanups (separate, focused commits if needed)
* Redundancy: generic blurbs repeated across files
* Multi-purpose dumps: keep commits **narrow and focused**
* Long explanations that good inline code comments already cover
**Guiding Principle:** Let code and inline docs speak. Use commits to highlight what isnt obvious.
---
# Copy-Paste Templates
## Minimal (no body)
```text
<type>(<scope>): <summary>
```
## Standard (with body & footer)
```text
<type>(<scope>)<!>: <summary>
<why-this-change?>
<what-it-does?>
<risks-or-follow-ups?>
Closes #<id>
BREAKING CHANGE: <impact + migration>
Co-authored-by: <Name> <email>
```
---
# Assistant Output Checklist (before showing the draft)
* [ ] List changed files + 12 line notes per file
* [ ] Provide **one** focused draft message (subject/body/footer)
* [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
* [ ] Body only if it adds non-obvious value
* [ ] No invented changes; aligns strictly with diffs
* [ ] Render as a single copy-paste block for the developer

View File

@@ -15,7 +15,7 @@ yarn-debug.log*
yarn-error.log*
# Build outputs
# dist - Allow dist directory for Docker builds (contains pre-built assets)
dist
dist-*
build
*.tsbuildinfo

View File

@@ -1,14 +1,10 @@
# Only the variables that start with VITE_ are seen in the application import.meta.env in Vue.
# Logging Configuration - Development environment gets maximum visibility
VITE_LOG_LEVEL=debug
# Only the variables that start with VITE_ are seen in the application import.meta.env in Vue.
# 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 this environment (not production).
VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZYYPS272F
VITE_DEFAULT_ENDORSER_API_SERVER=http://localhost:3000
# Using shared server by default to ease setup, which works for shared test users.

View File

@@ -1,7 +1,6 @@
# Only the variables that start with VITE_ are seen in the application import.meta.env in Vue.
# Logging Configuration - Production environment gets minimal logging for performance
VITE_LOG_LEVEL=warn
VITE_APP_SERVER=https://timesafari.app
# This is the claim ID for actions in the BVC project.

View File

@@ -1,14 +1,9 @@
# Only the variables that start with VITE_ are seen in the application import.meta.env in Vue.
# Logging Configuration - Test environment gets balanced logging for debugging
VITE_LOG_LEVEL=info
# iOS doesn't like spaces in the app title.
TIME_SAFARI_APP_TITLE="TimeSafari_Test"
VITE_APP_SERVER=https://test.timesafari.app
# This is the claim ID for actions in the BVC project, with the JWT ID on this environment (not
production).
# This is the claim ID for actions in the BVC project, with the JWT ID on this environment (not production).
VITE_BVC_MEETUPS_PROJECT_CLAIM_ID=https://endorser.ch/entity/01HWE8FWHQ1YGP7GFZYYPS272F
VITE_DEFAULT_ENDORSER_API_SERVER=https://test-api.endorser.ch

View File

@@ -30,7 +30,7 @@ module.exports = {
}],
"no-console": process.env.NODE_ENV === "production" ? "error" : "warn",
"no-debugger": process.env.NODE_ENV === "production" ? "error" : "warn",
"@typescript-eslint/no-explicit-any": "error",
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/explicit-function-return-type": "off",
"@typescript-eslint/no-unnecessary-type-constraint": "off",
"@typescript-eslint/no-unused-vars": ["error", { "argsIgnorePattern": "^_" }]

View File

@@ -1,142 +0,0 @@
name: Asset Validation & CI Safeguards
on:
pull_request:
paths:
- 'resources/**'
- 'config/assets/**'
- 'capacitor-assets.config.json'
- 'capacitor.config.ts'
- 'capacitor.config.json'
push:
branches: [main, develop]
paths:
- 'resources/**'
- 'config/assets/**'
- 'capacitor-assets.config.json'
- 'capacitor.config.ts'
- 'capacitor.config.json'
jobs:
asset-validation:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Validate asset configuration
run: npm run assets:validate
- name: Check for committed platform assets (Android)
run: |
if git ls-files -z android/app/src/main/res | grep -E '(AppIcon.*\.png|Splash.*\.png|mipmap-.*/ic_launcher.*\.png)' > /dev/null; then
echo "❌ Android platform assets found in VCS - these should be generated at build-time"
git ls-files -z android/app/src/main/res | grep -E '(AppIcon.*\.png|Splash.*\.png|mipmap-.*/ic_launcher.*\.png)'
exit 1
fi
echo "✅ No Android platform assets committed"
- name: Check for committed platform assets (iOS)
run: |
if git ls-files -z ios/App/App/Assets.xcassets | grep -E '(AppIcon.*\.png|Splash.*\.png)' > /dev/null; then
echo "❌ iOS platform assets found in VCS - these should be generated at build-time"
git ls-files -z ios/App/App/Assets.xcassets | grep -E '(AppIcon.*\.png|Splash.*\.png)'
exit 1
fi
echo "✅ No iOS platform assets committed"
- name: Test asset generation
run: |
echo "🧪 Testing asset generation workflow..."
npm run build:capacitor
npx cap sync
npx capacitor-assets generate --dry-run || npx capacitor-assets generate
echo "✅ Asset generation test completed"
- name: Verify clean tree after build
run: |
if [ -n "$(git status --porcelain)" ]; then
echo "❌ Dirty tree after build - asset configs were modified"
git status
git diff
exit 1
fi
echo "✅ Build completed with clean tree"
schema-validation:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Validate schema compliance
run: |
echo "🔍 Validating schema compliance..."
node -e "
const fs = require('fs');
const config = JSON.parse(fs.readFileSync('capacitor-assets.config.json', 'utf8'));
const schema = JSON.parse(fs.readFileSync('config/assets/schema.json', 'utf8'));
// Basic schema validation
if (!config.icon || !config.splash) {
throw new Error('Missing required sections: icon and splash');
}
if (!config.icon.source || !config.splash.source) {
throw new Error('Missing required source fields');
}
if (!/^resources\/.*\.(png|svg)$/.test(config.icon.source)) {
throw new Error('Icon source must be in resources/ directory');
}
if (!/^resources\/.*\.(png|svg)$/.test(config.splash.source)) {
throw new Error('Splash source must be in resources/ directory');
}
console.log('✅ Schema validation passed');
"
- name: Check source file existence
run: |
echo "📁 Checking source file existence..."
node -e "
const fs = require('fs');
const config = JSON.parse(fs.readFileSync('capacitor-assets.config.json', 'utf8'));
const requiredFiles = [
config.icon.source,
config.splash.source
];
if (config.splash.darkSource) {
requiredFiles.push(config.splash.darkSource);
}
const missingFiles = requiredFiles.filter(file => !fs.existsSync(file));
if (missingFiles.length > 0) {
console.error('❌ Missing source files:', missingFiles);
process.exit(1);
}
console.log('✅ All source files exist');
"

43
.gitignore vendored
View File

@@ -55,35 +55,7 @@ build_logs/
icons
*.log
# Build outputs
dist/
build/
# Generated Android assets and resources (should be generated during build)
android/app/src/main/assets/public/
# Generated Android resources (icons, splash screens, etc.)
android/app/src/main/res/drawable*/
android/app/src/main/res/mipmap*/
android/app/src/main/res/values/ic_launcher_background.xml
# Android generated assets (deny-listed in CI)
android/app/src/main/res/mipmap-*/ic_launcher*.png
android/app/src/main/res/drawable*/splash*.png
# iOS generated assets (deny-listed in CI)
ios/App/App/Assets.xcassets/**/AppIcon*.png
ios/App/App/Assets.xcassets/**/Splash*.png
# Keep these Android configuration files in version control:
# - android/app/src/main/assets/capacitor.plugins.json
# - android/app/src/main/res/values/strings.xml
# - android/app/src/main/res/values/styles.xml
# - android/app/src/main/res/layout/activity_main.xml
# - android/app/src/main/res/xml/config.xml
# - android/app/src/main/res/xml/file_paths.xml
android/app/src/main/res/
sql-wasm.wasm
# Temporary and generated files
@@ -111,7 +83,11 @@ ios/App/App/public/assets/
ios/App/App/build/
ios/App/build/
# Capacitor build artifacts (covered by android/app/build/ above)
# Capacitor generated configs (keep source configs)
android/app/build/intermediates/assets/debug/mergeDebugAssets/capacitor.*.json
android/app/build/intermediates/compressed_assets/debug/compressDebugAssets/out/assets/capacitor.*.json.jar
android/app/build/intermediates/merged_java_res/debug/mergeDebugJavaResource/feature-capacitor-cordova-android-plugins.jar
android/app/build/outputs/aar/capacitor-cordova-android-plugins-debug.aar
# Keep these Capacitor files in version control:
# - capacitor.config.json (root, electron, ios)
@@ -135,9 +111,4 @@ electron/out/
# - electron/electron-builder.config.json
# - electron/build-packages.sh
# - electron/live-runner.js
# - electron/resources/electron-publisher-custom.js
# Gradle cache files
android/.gradle/file-system.probe
android/.gradle/caches/
coverage
# - electron/resources/electron-publisher-custom.js

View File

@@ -1 +0,0 @@
18.19.0

1
.nvmrc
View File

@@ -1 +0,0 @@
18.19.0

File diff suppressed because it is too large Load Diff

View File

@@ -12,27 +12,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Deep link URLs (and other prod settings)
- Error in BVC begin view
## [1.0.6] - 2025.08.09
### Fixed
- Deep link errors where none would validate
## [1.0.5] - 2025.07.24
### Fixed
- Export & import of contacts corrupted contact methods
## [1.0.4] - 2025.07.20 - 002f2407208d56cc59c0aa7c880535ae4cbace8b
### Fixed
- Deep link for invite-one-accept
## [1.0.3] - 2025.07.12 - a9a8ba217cd6015321911e98e6843e988dc2c4ae
## [Unreleased]
### Changed
- Photo is pinned to profile mode
### Fixed
- Deep link URLs (and other prod settings)
- Error in BVC begin view
## [1.0.2] - 2025.06.20 - 276e0a741bc327de3380c4e508cccb7fee58c06d

View File

@@ -36,10 +36,6 @@
# Environment Variables:
# NODE_ENV: Build environment (development/production)
# BUILD_MODE: Build mode for asset selection (development/test/production)
#
# Build Context:
# This Dockerfile is designed to work when the build context is set to
# ./crowd-funder-for-time-pwa from the parent directory (where docker-compose.yml is located)
# =============================================================================
# BASE STAGE - Common dependencies and setup
@@ -66,7 +62,6 @@ RUN addgroup -g 1001 -S nodejs && \
WORKDIR /app
# Copy package files for dependency installation
# Note: These files are in the project root (crowd-funder-for-time-pwa directory)
COPY package*.json ./
# Install dependencies with security audit
@@ -87,7 +82,6 @@ ENV BUILD_MODE=${BUILD_MODE}
ENV NODE_ENV=${NODE_ENV}
# Copy pre-built assets from host
# Note: dist/ directory is in the project root (crowd-funder-for-time-pwa directory)
COPY dist/ ./dist/
# Verify build output exists
@@ -113,21 +107,23 @@ RUN apk update && \
curl \
&& rm -rf /var/cache/apk/*
# Use existing nginx user from base image (nginx user and group already exist)
# No need to create new user as nginx:alpine already has nginx user
# Create non-root user for nginx
RUN addgroup -g 1001 -S nginx && \
adduser -S nginx -u 1001 -G nginx
# Copy main nginx configuration
# Copy appropriate nginx configuration based on build mode
COPY docker/nginx.conf /etc/nginx/nginx.conf
# Copy production nginx configuration
COPY docker/default.conf /etc/nginx/conf.d/default.conf
# Copy staging configuration if needed
COPY docker/staging.conf /etc/nginx/conf.d/staging.conf
# Copy built assets from builder stage
COPY --from=builder --chown=nginx:nginx /app/dist /usr/share/nginx/html
# Create necessary directories with proper permissions
RUN mkdir -p /var/cache/nginx /var/log/nginx /tmp && \
chown -R nginx:nginx /var/cache/nginx /var/log/nginx /tmp && \
RUN mkdir -p /var/cache/nginx /var/log/nginx /var/run && \
chown -R nginx:nginx /var/cache/nginx /var/log/nginx /var/run && \
chown -R nginx:nginx /usr/share/nginx/html
# Switch to non-root user
@@ -143,6 +139,8 @@ HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
# Start nginx with proper signal handling
CMD ["nginx", "-g", "daemon off;"]
# =============================================================================
# TEST STAGE - For test environment testing
# =============================================================================

View File

@@ -1,4 +1,5 @@
source "https://rubygems.org"
gem "fastlane"
gem "cocoapods"

View File

@@ -22,7 +22,26 @@ GEM
algoliasearch (1.27.5)
httpclient (~> 2.8, >= 2.8.3)
json (>= 1.5.1)
artifactory (3.0.17)
atomos (0.1.3)
aws-eventstream (1.3.2)
aws-partitions (1.1066.0)
aws-sdk-core (3.220.1)
aws-eventstream (~> 1, >= 1.3.0)
aws-partitions (~> 1, >= 1.992.0)
aws-sigv4 (~> 1.9)
base64
jmespath (~> 1, >= 1.6.1)
aws-sdk-kms (1.99.0)
aws-sdk-core (~> 3, >= 3.216.0)
aws-sigv4 (~> 1.5)
aws-sdk-s3 (1.182.0)
aws-sdk-core (~> 3, >= 3.216.0)
aws-sdk-kms (~> 1)
aws-sigv4 (~> 1.5)
aws-sigv4 (1.11.0)
aws-eventstream (~> 1, >= 1.0.2)
babosa (1.0.4)
base64 (0.2.0)
benchmark (0.4.0)
bigdecimal (3.1.9)
@@ -64,13 +83,96 @@ GEM
nap (>= 0.8, < 2.0)
netrc (~> 0.11)
cocoapods-try (1.2.0)
colored (1.2)
colored2 (3.1.2)
commander (4.6.0)
highline (~> 2.0.0)
concurrent-ruby (1.3.5)
connection_pool (2.5.0)
declarative (0.0.20)
digest-crc (0.7.0)
rake (>= 12.0.0, < 14.0.0)
domain_name (0.6.20240107)
dotenv (2.8.1)
drb (2.2.1)
emoji_regex (3.2.3)
escape (0.0.4)
ethon (0.16.0)
ffi (>= 1.15.0)
excon (0.112.0)
faraday (1.10.4)
faraday-em_http (~> 1.0)
faraday-em_synchrony (~> 1.0)
faraday-excon (~> 1.1)
faraday-httpclient (~> 1.0)
faraday-multipart (~> 1.0)
faraday-net_http (~> 1.0)
faraday-net_http_persistent (~> 1.0)
faraday-patron (~> 1.0)
faraday-rack (~> 1.0)
faraday-retry (~> 1.0)
ruby2_keywords (>= 0.0.4)
faraday-cookie_jar (0.0.7)
faraday (>= 0.8.0)
http-cookie (~> 1.0.0)
faraday-em_http (1.0.0)
faraday-em_synchrony (1.0.0)
faraday-excon (1.1.0)
faraday-httpclient (1.0.1)
faraday-multipart (1.1.0)
multipart-post (~> 2.0)
faraday-net_http (1.0.2)
faraday-net_http_persistent (1.2.0)
faraday-patron (1.0.0)
faraday-rack (1.0.0)
faraday-retry (1.0.3)
faraday_middleware (1.2.1)
faraday (~> 1.0)
fastimage (2.4.0)
fastlane (2.227.0)
CFPropertyList (>= 2.3, < 4.0.0)
addressable (>= 2.8, < 3.0.0)
artifactory (~> 3.0)
aws-sdk-s3 (~> 1.0)
babosa (>= 1.0.3, < 2.0.0)
bundler (>= 1.12.0, < 3.0.0)
colored (~> 1.2)
commander (~> 4.6)
dotenv (>= 2.1.1, < 3.0.0)
emoji_regex (>= 0.1, < 4.0)
excon (>= 0.71.0, < 1.0.0)
faraday (~> 1.0)
faraday-cookie_jar (~> 0.0.6)
faraday_middleware (~> 1.0)
fastimage (>= 2.1.0, < 3.0.0)
fastlane-sirp (>= 1.0.0)
gh_inspector (>= 1.1.2, < 2.0.0)
google-apis-androidpublisher_v3 (~> 0.3)
google-apis-playcustomapp_v1 (~> 0.1)
google-cloud-env (>= 1.6.0, < 2.0.0)
google-cloud-storage (~> 1.31)
highline (~> 2.0)
http-cookie (~> 1.0.5)
json (< 3.0.0)
jwt (>= 2.1.0, < 3)
mini_magick (>= 4.9.4, < 5.0.0)
multipart-post (>= 2.0.0, < 3.0.0)
naturally (~> 2.2)
optparse (>= 0.1.1, < 1.0.0)
plist (>= 3.1.0, < 4.0.0)
rubyzip (>= 2.0.0, < 3.0.0)
security (= 0.1.5)
simctl (~> 1.6.3)
terminal-notifier (>= 2.0.0, < 3.0.0)
terminal-table (~> 3)
tty-screen (>= 0.6.3, < 1.0.0)
tty-spinner (>= 0.8.0, < 1.0.0)
word_wrap (~> 1.0.0)
xcodeproj (>= 1.13.0, < 2.0.0)
xcpretty (~> 0.4.0)
xcpretty-travis-formatter (>= 0.0.3, < 2.0.0)
fastlane-sirp (1.0.0)
sysrandom (~> 1.0)
ffi (1.17.1)
ffi (1.17.1-aarch64-linux-gnu)
ffi (1.17.1-aarch64-linux-musl)
@@ -85,27 +187,107 @@ GEM
fourflusher (2.3.1)
fuzzy_match (2.0.4)
gh_inspector (1.1.3)
google-apis-androidpublisher_v3 (0.54.0)
google-apis-core (>= 0.11.0, < 2.a)
google-apis-core (0.11.3)
addressable (~> 2.5, >= 2.5.1)
googleauth (>= 0.16.2, < 2.a)
httpclient (>= 2.8.1, < 3.a)
mini_mime (~> 1.0)
representable (~> 3.0)
retriable (>= 2.0, < 4.a)
rexml
google-apis-iamcredentials_v1 (0.17.0)
google-apis-core (>= 0.11.0, < 2.a)
google-apis-playcustomapp_v1 (0.13.0)
google-apis-core (>= 0.11.0, < 2.a)
google-apis-storage_v1 (0.31.0)
google-apis-core (>= 0.11.0, < 2.a)
google-cloud-core (1.8.0)
google-cloud-env (>= 1.0, < 3.a)
google-cloud-errors (~> 1.0)
google-cloud-env (1.6.0)
faraday (>= 0.17.3, < 3.0)
google-cloud-errors (1.5.0)
google-cloud-storage (1.47.0)
addressable (~> 2.8)
digest-crc (~> 0.4)
google-apis-iamcredentials_v1 (~> 0.1)
google-apis-storage_v1 (~> 0.31.0)
google-cloud-core (~> 1.6)
googleauth (>= 0.16.2, < 2.a)
mini_mime (~> 1.0)
googleauth (1.8.1)
faraday (>= 0.17.3, < 3.a)
jwt (>= 1.4, < 3.0)
multi_json (~> 1.11)
os (>= 0.9, < 2.0)
signet (>= 0.16, < 2.a)
highline (2.0.3)
http-cookie (1.0.8)
domain_name (~> 0.5)
httpclient (2.9.0)
mutex_m
i18n (1.14.7)
concurrent-ruby (~> 1.0)
jmespath (1.6.2)
json (2.10.2)
jwt (2.10.1)
base64
logger (1.6.6)
mini_magick (4.13.2)
mini_mime (1.1.5)
minitest (5.25.5)
molinillo (0.8.0)
multi_json (1.15.0)
multipart-post (2.4.1)
mutex_m (0.3.0)
nanaimo (0.4.0)
nap (1.1.0)
naturally (2.2.1)
netrc (0.11.0)
nkf (0.2.0)
optparse (0.6.0)
os (1.1.4)
plist (3.7.2)
public_suffix (4.0.7)
rake (13.2.1)
representable (3.2.0)
declarative (< 0.1.0)
trailblazer-option (>= 0.1.1, < 0.2.0)
uber (< 0.2.0)
retriable (3.1.2)
rexml (3.4.1)
rouge (3.28.0)
ruby-macho (2.5.1)
ruby2_keywords (0.0.5)
rubyzip (2.4.1)
securerandom (0.4.1)
security (0.1.5)
signet (0.19.0)
addressable (~> 2.8)
faraday (>= 0.17.5, < 3.a)
jwt (>= 1.5, < 3.0)
multi_json (~> 1.10)
simctl (1.6.10)
CFPropertyList
naturally
sysrandom (1.0.5)
terminal-notifier (2.0.0)
terminal-table (3.0.2)
unicode-display_width (>= 1.1.1, < 3)
trailblazer-option (0.1.2)
tty-cursor (0.7.1)
tty-screen (0.8.2)
tty-spinner (0.9.3)
tty-cursor (~> 0.7)
typhoeus (1.4.1)
ethon (>= 0.9.0)
tzinfo (2.0.6)
concurrent-ruby (~> 1.0)
uber (0.1.0)
unicode-display_width (2.6.0)
word_wrap (1.0.0)
xcodeproj (1.27.0)
CFPropertyList (>= 2.3.3, < 4.0)
atomos (~> 0.1.3)
@@ -113,6 +295,10 @@ GEM
colored2 (~> 3.1)
nanaimo (~> 0.4.0)
rexml (>= 3.3.6, < 4.0)
xcpretty (0.4.0)
rouge (~> 3.28.0)
xcpretty-travis-formatter (1.0.1)
xcpretty (~> 0.2, >= 0.0.7)
PLATFORMS
aarch64-linux-gnu
@@ -129,6 +315,7 @@ PLATFORMS
DEPENDENCIES
cocoapods
fastlane
BUNDLED WITH
2.6.5

144
README.md
View File

@@ -3,9 +3,36 @@
[Time Safari](https://timesafari.org/) allows people to ease into collaboration: start with expressions of gratitude
and expand to crowd-fund with time & money, then record and see the impact of contributions.
## Database Migration Status
**Current Status**: The application is undergoing a migration from Dexie (IndexedDB) to SQLite using absurd-sql. This migration is in **Phase 2** with a well-defined migration fence in place.
### Migration Progress
-**SQLite Database Service**: Fully implemented with absurd-sql
-**Platform Service Layer**: Unified database interface across platforms
-**Settings Migration**: Core user settings transferred
-**Account Migration**: Identity and key management
- 🔄 **Contact Migration**: User contact data (via import interface)
- 📋 **Code Cleanup**: Remove unused Dexie imports
### Migration Fence
The migration is controlled by a **migration fence** that separates legacy Dexie code from the new SQLite implementation. See [Migration Fence Definition](doc/migration-fence-definition.md) for complete details.
**Key Points**:
- Legacy Dexie database is disabled by default
- All database operations go through `PlatformServiceMixin`
- Migration tools provide controlled access to both databases
- Clear separation between legacy and new code
### Migration Documentation
- [Migration Guide](doc/migration-to-wa-sqlite.md) - Complete migration process
- [Migration Fence Definition](doc/migration-fence-definition.md) - Fence boundaries and rules
- [Database Migration Guide](doc/database-migration-guide.md) - User-facing migration tools
## Roadmap
See [ClickUp](https://sharing.clickup.com/9014278710/l/h/8cmnyhp-174/10573fec74e2ba0) for current priorities.
See [project.task.yaml](project.task.yaml) for current priorities.
(Numbers at the beginning of lines are estimated hours. See [taskyaml.org](https://taskyaml.org/) for details.)
## Setup & Building
@@ -15,45 +42,14 @@ Quick start:
```bash
npm install
npm run build:web:serve -- --test
npm run dev
```
To be able to make submissions: go to "profile" (bottom left), go to the bottom and expand "Show Advanced Settings", go to the bottom and to the "Test Page", and finally "Become User 0" to see all the functionality.
See [BUILDING.md](BUILDING.md) for comprehensive build instructions for all platforms (Web, Electron, iOS, Android, Docker).
## Development Database Clearing
TimeSafari provides a simple script-based approach to clear the local database (not the claim server) for development purposes.
## Logging Configuration
TimeSafari supports configurable logging levels via the `VITE_LOG_LEVEL` environment variable. This allows developers to control console output verbosity without modifying code.
### Quick Usage
```bash
# Show only errors
VITE_LOG_LEVEL=error npm run dev
# Show warnings and errors
VITE_LOG_LEVEL=warn npm run dev
# Show info, warnings, and errors (default)
VITE_LOG_LEVEL=info npm run dev
# Show all log levels including debug
VITE_LOG_LEVEL=debug npm run dev
```
### Available Levels
- **`error`**: Critical errors only
- **`warn`**: Warnings and errors (default for production web)
- **`info`**: Info, warnings, and errors (default for development/capacitor)
- **`debug`**: All log levels including verbose debugging
See [Logging Configuration Guide](doc/logging-configuration.md) for complete details.
TimeSafari provides a simple script-based approach to clear the database for development purposes.
### Quick Usage
```bash
@@ -101,85 +97,25 @@ rmdir /s /q %APPDATA%\TimeSafari
```bash
# Create isolated browser profile
mkdir ~/timesafari-dev-data
# Start browser with custom profile
google-chrome --user-data-dir=~/timesafari-dev-data
# Clear when needed
rm -rf ~/timesafari-dev-data
```
## Domain Configuration
TimeSafari uses a centralized domain configuration system to ensure consistent
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
-**Single Point of Control**: Change domain in one place for entire app
-**Type-Safe Configuration**: Full TypeScript support
### Quick Reference
```typescript
// For sharing functionality (environment-specific)
import { APP_SERVER } from "@/constants/app";
const shareLink = `${APP_SERVER}/deep-link/claim/123`;
// For internal operations (environment-specific)
import { APP_SERVER } from "@/constants/app";
const apiUrl = `${APP_SERVER}/api/claim/123`;
```
### Documentation
- [Constants and Configuration](src/constants/app.ts) - Core constants
See the script for complete platform-specific instructions.
## Tests
See [TESTING.md](test-playwright/TESTING.md) for detailed test instructions.
## Asset Management
## Icons
TimeSafari uses a standardized asset configuration system for consistent
icon and splash screen generation across all platforms.
Application icons are in the `assets` directory, processed by the `capacitor-assets` command.
### Asset Sources
- **Single source of truth**: `resources/` directory (Capacitor default)
- **Source files**: `icon.png`, `splash.png`, `splash_dark.png`
- **Format**: PNG or SVG files for optimal quality
### Asset Generation
- **Configuration**: `config/assets/capacitor-assets.config.json`
- **Schema validation**: `config/assets/schema.json`
- **Build-time generation**: Platform assets generated via `capacitor-assets`
- **No VCS commits**: Generated assets are never committed to version control
### Development Commands
```bash
# Generate/update asset configurations
npm run assets:config
# Validate asset configurations
npm run assets:validate
# Clean generated platform assets (local dev only)
npm run assets:clean
# Build with asset generation
npm run build:native
```
### Platform Support
- **Android**: Adaptive icons with foreground/background, monochrome support
- **iOS**: LaunchScreen storyboard preferred, splash assets when needed
- **Web**: PWA icons generated during build to `dist/` (not committed)
### Font Awesome Icons
To add a Font Awesome icon, add to `fontawesome.ts` and reference with
`font-awesome` element and `icon` attribute with the hyphenated name.
To add a Font Awesome icon, add to main.ts and reference with `font-awesome` element and `icon` attribute with the hyphenated name.
## Other

7
android/.gitignore vendored
View File

@@ -84,6 +84,13 @@ freeline.py
freeline/
freeline_project_description.json
# fastlane
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output
fastlane/readme.md
# Version control
vcs.xml

View File

@@ -31,8 +31,8 @@ android {
applicationId "app.timesafari.app"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode 39
versionName "1.0.6"
versionCode 35
versionName "1.0.2"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
aaptOptions {
// Files and dirs to omit from the packaged assets dir, modified to accommodate modern web apps.
@@ -64,14 +64,6 @@ android {
}
}
}
packagingOptions {
jniLibs {
pickFirsts += ['**/lib/x86_64/libbarhopper_v3.so', '**/lib/x86_64/libimage_processing_util_jni.so', '**/lib/x86_64/libsqlcipher.so']
}
}
// Configure for 16 KB page size compatibility
// Enable bundle builds (without which it doesn't work right for bundleDebug vs bundleRelease)
bundle {

View File

@@ -29,7 +29,7 @@
"splashFullScreen": true,
"splashImmersive": true
},
"CapSQLite": {
"CapacitorSQLite": {
"iosDatabaseLocation": "Library/CapacitorDatabase",
"iosIsEncryption": false,
"iosBiometric": {
@@ -57,14 +57,13 @@
]
},
"android": {
"allowMixedContent": true,
"allowMixedContent": false,
"captureInput": true,
"webContentsDebuggingEnabled": false,
"allowNavigation": [
"*.timesafari.app",
"*.jsdelivr.net",
"api.endorser.ch",
"10.0.2.2:3000"
"api.endorser.ch"
]
},
"electron": {

View File

View File

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 270 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 332 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 463 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

View File

@@ -0,0 +1,86 @@
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg version="1.0" xmlns="http://www.w3.org/2000/svg"
width="512.000000pt" height="512.000000pt" viewBox="0 0 512.000000 512.000000"
preserveAspectRatio="xMidYMid meet">
<g transform="translate(0.000000,512.000000) scale(0.100000,-0.100000)"
fill="#000000" stroke="none">
<path d="M2480 4005 c-25 -7 -58 -20 -75 -29 -16 -9 -40 -16 -52 -16 -17 0
-24 -7 -28 -27 -3 -16 -14 -45 -24 -65 -21 -41 -13 -55 18 -38 25 13 67 13 92
-1 15 -8 35 -4 87 17 99 39 130 41 197 10 64 -29 77 -31 107 -15 20 11 20 11
-3 35 -12 13 -30 24 -38 24 -24 1 -132 38 -148 51 -8 7 -11 20 -7 32 12 37
-40 47 -126 22z"/>
<path d="M1450 3775 c-7 -8 -18 -15 -24 -15 -7 0 -31 -14 -54 -32 -29 -22 -38
-34 -29 -40 17 -11 77 -10 77 1 0 5 16 16 35 25 60 29 220 19 290 -18 17 -9
33 -16 37 -16 4 0 31 -15 60 -34 108 -70 224 -215 282 -353 30 -71 53 -190 42
-218 -10 -27 -23 -8 -52 75 -30 90 -88 188 -120 202 -13 6 -26 9 -29 6 -3 -2
11 -51 30 -108 28 -83 35 -119 35 -179 0 -120 -22 -127 -54 -17 -11 37 -13 21
-18 -154 -5 -180 -8 -200 -32 -264 -51 -132 -129 -245 -199 -288 -21 -12 -79
-49 -129 -80 -161 -102 -294 -141 -473 -141 -228 0 -384 76 -535 259 -81 99
-118 174 -154 312 -31 121 -35 273 -11 437 19 127 19 125 -4 125 -23 0 -51
-34 -87 -104 -14 -28 -33 -64 -41 -81 -19 -34 -22 -253 -7 -445 9 -106 12
-119 44 -170 19 -30 42 -67 50 -81 64 -113 85 -140 130 -169 28 -18 53 -44 61
-62 8 -20 36 -45 83 -76 62 -39 80 -46 151 -54 44 -5 96 -13 115 -18 78 -20
238 -31 282 -19 24 6 66 8 95 5 76 -9 169 24 319 114 32 19 80 56 106 82 27
26 52 48 58 48 5 0 27 26 50 58 48 66 56 70 132 71 62 1 165 29 238 64 112 55
177 121 239 245 37 76 39 113 10 267 -12 61 -23 131 -26 156 -5 46 -5 47 46
87 92 73 182 70 263 -8 l51 -49 -6 -61 c-4 -34 -13 -85 -21 -113 -28 -103 -30
-161 -4 -228 16 -44 32 -67 55 -83 18 -11 39 -37 47 -58 10 -23 37 -53 73 -81
32 -25 69 -57 82 -71 14 -14 34 -26 47 -26 12 0 37 -7 56 -15 20 -8 66 -17
104 -20 107 -10 110 -11 150 -71 50 -75 157 -177 197 -187 18 -5 53 -24 78
-42 71 -51 176 -82 304 -89 61 -4 127 -12 147 -18 29 -9 45 -8 77 6 23 9 50
16 60 16 31 0 163 46 216 76 28 15 75 46 105 69 30 23 69 49 85 58 17 8 46 31
64 51 19 20 40 36 47 36 18 0 77 70 100 120 32 66 45 108 55 173 5 32 16 71
24 87 43 84 43 376 0 549 -27 105 -43 127 -135 188 -30 21 -65 46 -77 57 -13
11 -23 17 -23 14 0 -3 21 -46 47 -94 79 -151 85 -166 115 -263 25 -83 28 -110
28 -226 0 -144 -17 -221 -75 -335 -39 -77 -208 -244 -304 -299 -451 -263 -975
-67 -1138 426 -23 70 -26 95 -28 254 -1 108 -7 183 -14 196 -6 12 -11 31 -11
43 0 32 31 122 52 149 10 13 18 28 18 34 0 5 25 40 56 78 60 73 172 170 219
190 30 12 30 13 6 17 -15 2 -29 -2 -37 -12 -6 -9 -16 -16 -22 -16 -6 0 -23
-11 -39 -24 -15 -12 -33 -25 -40 -27 -17 -6 -82 -60 -117 -97 -65 -70 -75 -82
-107 -133 -23 -34 -35 -46 -37 -35 -3 16 20 87 44 134 6 12 9 34 6 48 -4 22
-8 25 -31 19 -14 -3 -38 -15 -53 -26 -34 -24 -34 -21 -6 28 65 112 184 206
291 227 15 3 39 9 55 12 l27 6 -24 9 c-90 35 -304 -66 -478 -225 -39 -36 -74
-66 -77 -66 -22 0 18 82 72 148 19 23 32 46 28 49 -4 4 -26 13 -49 19 -73 21
-161 54 -171 64 -6 6 -20 10 -32 10 -21 0 -21 -1 -8 -40 45 -130 8 -247 -93
-299 -25 -13 -31 0 -14 29 15 22 1 33 -22 17 -56 -36 -117 -22 -117 28 0 13
-16 47 -35 76 -22 34 -33 60 -29 73 4 16 -3 26 -26 39 -16 10 -30 21 -30 25 1
18 54 64 87 76 l38 13 -33 5 c-30 4 -115 -18 -154 -42 -13 -7 -20 -5 -27 8 -9
16 -12 16 -53 1 -160 -61 -258 -104 -258 -114 0 -7 10 -20 21 -31 103 -91 217
-297 249 -449 28 -135 41 -237 35 -276 -14 -91 -48 -170 -97 -220 -44 -47 -68
-60 -68 -40 0 6 4 12 8 15 5 3 24 35 42 72 l33 67 -6 141 c-4 103 -11 158 -26
205 -12 35 -21 70 -21 77 0 7 -20 56 -45 108 -82 173 -227 322 -392 401 -67
33 -90 39 -163 42 -108 5 -130 10 -130 28 0 20 -63 20 -80 0z"/>
<path d="M3710 3765 c0 -20 8 -28 39 -41 22 -8 42 -22 45 -30 5 -14 42 -19 70
-8 10 4 -7 21 -58 55 -41 27 -79 49 -85 49 -6 0 -11 -11 -11 -25z"/>
<path d="M3173 3734 c-9 -25 10 -36 35 -18 12 8 22 19 22 25 0 16 -50 10 -57
-7z"/>
<path d="M1982 3728 c6 -16 36 -34 44 -26 3 4 4 14 1 23 -7 17 -51 21 -45 3z"/>
<path d="M1540 3620 c0 -5 7 -10 16 -10 8 0 12 5 9 10 -3 6 -10 10 -16 10 -5
0 -9 -4 -9 -10z"/>
<path d="M4467 3624 c-4 -4 23 -27 60 -50 84 -56 99 -58 67 -9 -28 43 -107 79
-127 59z"/>
<path d="M655 3552 c-11 -2 -26 -9 -33 -14 -7 -6 -27 -18 -45 -27 -36 -18 -58
-64 -39 -83 9 -9 25 1 70 43 53 48 78 78 70 84 -2 1 -12 -1 -23 -3z"/>
<path d="M1015 3460 c-112 -24 -247 -98 -303 -165 -53 -65 -118 -214 -136
-311 -20 -113 -20 -145 -1 -231 20 -88 49 -153 102 -230 79 -113 186 -182 331
-214 108 -24 141 -24 247 1 130 30 202 72 316 181 102 100 153 227 152 384 0
142 -58 293 -150 395 -60 67 -180 145 -261 171 -75 23 -232 34 -297 19z m340
-214 c91 -43 174 -154 175 -234 0 -18 -9 -51 -21 -73 -19 -37 -19 -42 -5 -64
35 -54 12 -121 -48 -142 -22 -7 -47 -19 -55 -27 -9 -8 -41 -27 -71 -42 -50
-26 -64 -29 -155 -29 -111 0 -152 14 -206 68 -49 49 -63 85 -64 162 0 59 4 78
28 118 31 52 96 105 141 114 23 5 33 17 56 68 46 103 121 130 225 81z"/>
<path d="M3985 3464 c-44 -7 -154 -44 -200 -67 -55 -28 -138 -96 -162 -132
-10 -16 -39 -75 -64 -130 l-44 -100 0 -160 0 -160 45 -90 c53 -108 152 -214
245 -264 59 -31 215 -71 281 -71 53 0 206 40 255 67 98 53 203 161 247 253 53
113 74 193 74 280 -1 304 -253 564 -557 575 -49 2 -103 1 -120 -1z m311 -220
c129 -68 202 -209 160 -309 -15 -35 -15 -42 -1 -72 26 -55 -3 -118 -59 -129
-19 -3 -43 -15 -53 -26 -26 -29 -99 -64 -165 -78 -45 -10 -69 -10 -120 -1 -74
15 -113 37 -161 91 -110 120 -50 331 109 385 24 8 44 23 52 39 6 14 18 38 25
53 33 72 127 93 213 47z"/>
<path d="M487 3394 c-21 -12 -27 -21 -25 -40 2 -14 7 -26 12 -27 14 -3 48 48
44 66 -3 14 -6 14 -31 1z"/>
</g>
</svg>

After

Width:  |  Height:  |  Size: 5.6 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 705 KiB

View File

@@ -0,0 +1,11 @@
Model Information:
* title: Lupine Plant
* source: https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439
* author: rufusrockwell (https://sketchfab.com/rufusrockwell)
Model License:
* license type: CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)
* requirements: Author must be credited. Commercial use is allowed.
If you use this 3D model in your project be sure to copy paste this credit wherever you share it:
This work is based on "Lupine Plant" (https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439) by rufusrockwell (https://sketchfab.com/rufusrockwell) licensed under CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)

View File

@@ -0,0 +1,229 @@
{
"accessors": [
{
"bufferView": 2,
"componentType": 5126,
"count": 2759,
"max": [
41.3074951171875,
40.37548828125,
87.85917663574219
],
"min": [
-35.245540618896484,
-36.895416259765625,
-0.9094290137290955
],
"type": "VEC3"
},
{
"bufferView": 2,
"byteOffset": 33108,
"componentType": 5126,
"count": 2759,
"max": [
0.9999382495880127,
0.9986748695373535,
0.9985831379890442
],
"min": [
-0.9998949766159058,
-0.9975876212120056,
-0.411094069480896
],
"type": "VEC3"
},
{
"bufferView": 3,
"componentType": 5126,
"count": 2759,
"max": [
0.9987699389457703,
0.9998998045921326,
0.9577858448028564,
1.0
],
"min": [
-0.9987726807594299,
-0.9990445971488953,
-0.999801516532898,
1.0
],
"type": "VEC4"
},
{
"bufferView": 1,
"componentType": 5126,
"count": 2759,
"max": [
1.0061479806900024,
0.9993550181388855
],
"min": [
0.00279300007969141,
0.0011620000004768372
],
"type": "VEC2"
},
{
"bufferView": 0,
"componentType": 5125,
"count": 6378,
"type": "SCALAR"
}
],
"asset": {
"extras": {
"author": "rufusrockwell (https://sketchfab.com/rufusrockwell)",
"license": "CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)",
"source": "https://sketchfab.com/3d-models/lupine-plant-bf30f1110c174d4baedda0ed63778439",
"title": "Lupine Plant"
},
"generator": "Sketchfab-12.68.0",
"version": "2.0"
},
"bufferViews": [
{
"buffer": 0,
"byteLength": 25512,
"name": "floatBufferViews",
"target": 34963
},
{
"buffer": 0,
"byteLength": 22072,
"byteOffset": 25512,
"byteStride": 8,
"name": "floatBufferViews",
"target": 34962
},
{
"buffer": 0,
"byteLength": 66216,
"byteOffset": 47584,
"byteStride": 12,
"name": "floatBufferViews",
"target": 34962
},
{
"buffer": 0,
"byteLength": 44144,
"byteOffset": 113800,
"byteStride": 16,
"name": "floatBufferViews",
"target": 34962
}
],
"buffers": [
{
"byteLength": 157944,
"uri": "scene.bin"
}
],
"images": [
{
"uri": "textures/lambert2SG_baseColor.png"
},
{
"uri": "textures/lambert2SG_normal.png"
}
],
"materials": [
{
"alphaCutoff": 0.2,
"alphaMode": "MASK",
"doubleSided": true,
"name": "lambert2SG",
"normalTexture": {
"index": 1
},
"pbrMetallicRoughness": {
"baseColorTexture": {
"index": 0
},
"metallicFactor": 0.0
}
}
],
"meshes": [
{
"name": "Object_0",
"primitives": [
{
"attributes": {
"NORMAL": 1,
"POSITION": 0,
"TANGENT": 2,
"TEXCOORD_0": 3
},
"indices": 4,
"material": 0,
"mode": 4
}
]
}
],
"nodes": [
{
"children": [
1
],
"matrix": [
1.0,
0.0,
0.0,
0.0,
0.0,
2.220446049250313e-16,
-1.0,
0.0,
0.0,
1.0,
2.220446049250313e-16,
0.0,
0.0,
0.0,
0.0,
1.0
],
"name": "Sketchfab_model"
},
{
"children": [
2
],
"name": "LupineSF.obj.cleaner.materialmerger.gles"
},
{
"mesh": 0,
"name": "Object_2"
}
],
"samplers": [
{
"magFilter": 9729,
"minFilter": 9987,
"wrapS": 10497,
"wrapT": 10497
}
],
"scene": 0,
"scenes": [
{
"name": "Sketchfab_Scene",
"nodes": [
0
]
}
],
"textures": [
{
"sampler": 0,
"source": 0
},
{
"sampler": 0,
"source": 1
}
]
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.7 MiB

View File

@@ -0,0 +1,2 @@
User-agent: *
Disallow:

View File

@@ -0,0 +1,34 @@
<vector xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:aapt="http://schemas.android.com/aapt"
android:width="108dp"
android:height="108dp"
android:viewportHeight="108"
android:viewportWidth="108">
<path
android:fillType="evenOdd"
android:pathData="M32,64C32,64 38.39,52.99 44.13,50.95C51.37,48.37 70.14,49.57 70.14,49.57L108.26,87.69L108,109.01L75.97,107.97L32,64Z"
android:strokeColor="#00000000"
android:strokeWidth="1">
<aapt:attr name="android:fillColor">
<gradient
android:endX="78.5885"
android:endY="90.9159"
android:startX="48.7653"
android:startY="61.0927"
android:type="linear">
<item
android:color="#44000000"
android:offset="0.0" />
<item
android:color="#00000000"
android:offset="1.0" />
</gradient>
</aapt:attr>
</path>
<path
android:fillColor="#FFFFFF"
android:fillType="nonZero"
android:pathData="M66.94,46.02L66.94,46.02C72.44,50.07 76,56.61 76,64L32,64C32,56.61 35.56,50.11 40.98,46.06L36.18,41.19C35.45,40.45 35.45,39.3 36.18,38.56C36.91,37.81 38.05,37.81 38.78,38.56L44.25,44.05C47.18,42.57 50.48,41.71 54,41.71C57.48,41.71 60.78,42.57 63.68,44.05L69.11,38.56C69.84,37.81 70.98,37.81 71.71,38.56C72.44,39.3 72.44,40.45 71.71,41.19L66.94,46.02ZM62.94,56.92C64.08,56.92 65,56.01 65,54.88C65,53.76 64.08,52.85 62.94,52.85C61.8,52.85 60.88,53.76 60.88,54.88C60.88,56.01 61.8,56.92 62.94,56.92ZM45.06,56.92C46.2,56.92 47.13,56.01 47.13,54.88C47.13,53.76 46.2,52.85 45.06,52.85C43.92,52.85 43,53.76 43,54.88C43,56.01 43.92,56.92 45.06,56.92Z"
android:strokeColor="#00000000"
android:strokeWidth="1" />
</vector>

View File

@@ -0,0 +1,170 @@
<?xml version="1.0" encoding="utf-8"?>
<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:width="108dp"
android:height="108dp"
android:viewportHeight="108"
android:viewportWidth="108">
<path
android:fillColor="#26A69A"
android:pathData="M0,0h108v108h-108z" />
<path
android:fillColor="#00000000"
android:pathData="M9,0L9,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,0L19,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M29,0L29,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M39,0L39,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M49,0L49,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M59,0L59,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M69,0L69,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M79,0L79,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M89,0L89,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M99,0L99,108"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,9L108,9"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,19L108,19"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,29L108,29"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,39L108,39"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,49L108,49"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,59L108,59"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,69L108,69"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,79L108,79"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,89L108,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M0,99L108,99"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,29L89,29"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,39L89,39"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,49L89,49"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,59L89,59"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,69L89,69"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M19,79L89,79"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M29,19L29,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M39,19L39,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M49,19L49,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M59,19L59,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M69,19L69,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
<path
android:fillColor="#00000000"
android:pathData="M79,19L79,89"
android:strokeColor="#33FFFFFF"
android:strokeWidth="0.8" />
</vector>

View File

@@ -0,0 +1,9 @@
<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
<background>
<inset android:drawable="@mipmap/ic_launcher_background" android:inset="16.7%" />
</background>
<foreground>
<inset android:drawable="@mipmap/ic_launcher_foreground" android:inset="16.7%" />
</foreground>
</adaptive-icon>

View File

@@ -0,0 +1,9 @@
<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
<background>
<inset android:drawable="@mipmap/ic_launcher_background" android:inset="16.7%" />
</background>
<foreground>
<inset android:drawable="@mipmap/ic_launcher_foreground" android:inset="16.7%" />
</foreground>
</adaptive-icon>

View File

@@ -1,7 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<resources>
<color name="colorPrimary">#3F51B5</color>
<color name="colorPrimaryDark">#303F9F</color>
<color name="colorAccent">#FF4081</color>
<color name="ic_launcher_background">#FFFFFF</color>
</resources>

View File

@@ -0,0 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<resources>
<color name="ic_launcher_background">#FFFFFF</color>
</resources>

View File

@@ -7,7 +7,7 @@ buildscript {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:8.12.0'
classpath 'com.android.tools.build:gradle:8.11.0'
classpath 'com.google.gms:google-services:4.4.0'
// NOTE: Do not place your application dependencies here; they belong

View File

@@ -20,4 +20,4 @@ org.gradle.jvmargs=-Xmx1536m
# Android operating system, and which are packaged with your app's APK
# https://developer.android.com/topic/libraries/support-library/androidx-rn
android.useAndroidX=true
android.suppressUnsupportedCompileSdk=36
android.suppressUnsupportedCompileSdk=34

View File

@@ -1,7 +1,7 @@
ext {
minSdkVersion = 22
compileSdkVersion = 36
targetSdkVersion = 36
compileSdkVersion = 34
targetSdkVersion = 34
androidxActivityVersion = '1.8.0'
androidxAppCompatVersion = '1.6.1'
androidxCoordinatorLayoutVersion = '1.2.0'

2
assets/README.md Normal file
View File

@@ -0,0 +1,2 @@
Application icons are here. They are processed for android & ios by the `capacitor-assets` command, as indicated in the BUILDING.md file.

View File

Before

Width:  |  Height:  |  Size: 279 KiB

After

Width:  |  Height:  |  Size: 279 KiB

View File

Before

Width:  |  Height:  |  Size: 1.9 MiB

After

Width:  |  Height:  |  Size: 1.9 MiB

View File

Before

Width:  |  Height:  |  Size: 1.9 MiB

After

Width:  |  Height:  |  Size: 1.9 MiB

View File

@@ -1,32 +0,0 @@
{
"icon": {
"android": {
"adaptive": {
"background": "#121212",
"foreground": "resources/icon.png",
"monochrome": "resources/icon.png"
},
"target": "android/app/src/main/res"
},
"ios": {
"padding": 0,
"target": "ios/App/App/Assets.xcassets/AppIcon.appiconset"
},
"source": "resources/icon.png",
"web": {
"target": "public/img/icons"
}
},
"splash": {
"android": {
"scale": "cover",
"target": "android/app/src/main/res"
},
"darkSource": "resources/splash_dark.png",
"ios": {
"target": "ios/App/App/Assets.xcassets",
"useStoryBoard": true
},
"source": "resources/splash.png"
}
}

View File

@@ -57,14 +57,13 @@
]
},
"android": {
"allowMixedContent": true,
"allowMixedContent": false,
"captureInput": true,
"webContentsDebuggingEnabled": false,
"allowNavigation": [
"*.timesafari.app",
"*.jsdelivr.net",
"api.endorser.ch",
"10.0.2.2:3000"
"api.endorser.ch"
]
},
"electron": {

View File

@@ -1,116 +0,0 @@
import { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'app.timesafari',
appName: 'TimeSafari',
webDir: 'dist',
server: {
cleartext: true
},
plugins: {
App: {
appUrlOpen: {
handlers: [
{
url: 'timesafari://*',
autoVerify: true
}
]
}
},
SplashScreen: {
launchShowDuration: 3000,
launchAutoHide: true,
backgroundColor: '#ffffff',
androidSplashResourceName: 'splash',
androidScaleType: 'CENTER_CROP',
showSpinner: false,
androidSpinnerStyle: 'large',
iosSpinnerStyle: 'small',
spinnerColor: '#999999',
splashFullScreen: true,
splashImmersive: true
},
CapSQLite: {
iosDatabaseLocation: 'Library/CapacitorDatabase',
iosIsEncryption: false,
iosBiometric: {
biometricAuth: false,
biometricTitle: 'Biometric login for TimeSafari'
},
androidIsEncryption: false,
androidBiometric: {
biometricAuth: false,
biometricTitle: 'Biometric login for TimeSafari'
},
electronIsEncryption: false
}
},
ios: {
contentInset: 'never',
allowsLinkPreview: true,
scrollEnabled: true,
limitsNavigationsToAppBoundDomains: true,
backgroundColor: '#ffffff',
allowNavigation: [
'*.timesafari.app',
'*.jsdelivr.net',
'api.endorser.ch'
]
},
android: {
allowMixedContent: true,
captureInput: true,
webContentsDebuggingEnabled: false,
allowNavigation: [
'*.timesafari.app',
'*.jsdelivr.net',
'api.endorser.ch',
'10.0.2.2:3000'
]
},
electron: {
deepLinking: {
schemes: ['timesafari']
},
buildOptions: {
appId: 'app.timesafari',
productName: 'TimeSafari',
directories: {
output: 'dist-electron-packages'
},
files: [
'dist/**/*',
'electron/**/*'
],
mac: {
category: 'public.app-category.productivity',
target: [
{
target: 'dmg',
arch: ['x64', 'arm64']
}
]
},
win: {
target: [
{
target: 'nsis',
arch: ['x64']
}
]
},
linux: {
target: [
{
target: 'AppImage',
arch: ['x64']
}
],
category: 'Utility'
}
}
}
};
export default config;

View File

@@ -1,32 +0,0 @@
{
"icon": {
"android": {
"adaptive": {
"background": "#121212",
"foreground": "resources/icon.png",
"monochrome": "resources/icon.png"
},
"target": "android/app/src/main/res"
},
"ios": {
"padding": 0,
"target": "ios/App/App/Assets.xcassets/AppIcon.appiconset"
},
"source": "resources/icon.png",
"web": {
"target": "public/img/icons"
}
},
"splash": {
"android": {
"scale": "cover",
"target": "android/app/src/main/res"
},
"darkSource": "resources/splash_dark.png",
"ios": {
"target": "ios/App/App/Assets.xcassets",
"useStoryBoard": true
},
"source": "resources/splash.png"
}
}

View File

@@ -1,119 +0,0 @@
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Capacitor Assets Configuration Schema",
"description": "Schema for validating capacitor-assets configuration files",
"type": "object",
"properties": {
"icon": {
"type": "object",
"properties": {
"source": {
"type": "string",
"pattern": "^resources/.*\\.(png|svg)$",
"description": "Source icon file path relative to project root"
},
"android": {
"type": "object",
"properties": {
"adaptive": {
"type": "object",
"properties": {
"foreground": {
"type": "string",
"pattern": "^resources/.*\\.(png|svg)$",
"description": "Foreground icon for Android adaptive icons"
},
"background": {
"type": ["string", "object"],
"description": "Background color or image for adaptive icons"
},
"monochrome": {
"type": "string",
"pattern": "^resources/.*\\.(png|svg)$",
"description": "Monochrome icon for Android 13+"
}
},
"required": ["foreground", "background"]
},
"target": {
"type": "string",
"description": "Android target directory for generated icons"
}
}
},
"ios": {
"type": "object",
"properties": {
"padding": {
"type": "number",
"minimum": 0,
"maximum": 1,
"description": "Padding ratio for iOS icons"
},
"target": {
"type": "string",
"description": "iOS target directory for generated icons"
}
}
},
"web": {
"type": "object",
"properties": {
"target": {
"type": "string",
"description": "Web target directory for generated icons"
}
}
}
},
"required": ["source"],
"additionalProperties": false
},
"splash": {
"type": "object",
"properties": {
"source": {
"type": "string",
"pattern": "^resources/.*\\.(png|svg)$",
"description": "Source splash screen file"
},
"darkSource": {
"type": "string",
"pattern": "^resources/.*\\.(png|svg)$",
"description": "Dark mode splash screen file"
},
"android": {
"type": "object",
"properties": {
"scale": {
"type": "string",
"enum": ["cover", "contain", "fill"],
"description": "Android splash screen scaling mode"
},
"target": {
"type": "string",
"description": "Android target directory for splash screens"
}
}
},
"ios": {
"type": "object",
"properties": {
"useStoryBoard": {
"type": "boolean",
"description": "Use LaunchScreen storyboard instead of splash assets"
},
"target": {
"type": "string",
"description": "iOS target directory for splash screens"
}
}
}
},
"required": ["source"],
"additionalProperties": false
}
},
"required": ["icon", "splash"],
"additionalProperties": false
}

View File

@@ -1,214 +0,0 @@
# TimeSafari Asset Configuration Migration Plan
**Author**: Matthew Raymer
**Date**: 2025-08-14
**Status**: 🎯 **IMPLEMENTATION** - Ready for Execution
## Overview
This document outlines the migration from the current mixed asset management
system to a standardized, single-source asset configuration approach using
`capacitor-assets` as the standard generator.
## Current State Analysis
### Asset Sources (Duplicated)
- **`assets/` directory**: Contains `icon.png`, `splash.png`, `splash_dark.png`
- **`resources/` directory**: Contains identical files in platform-specific subdirectories
- **Result**: Duplicate storage, confusion about source of truth
### Asset Generation (Manual)
- **Custom scripts**: `generate-icons.sh`, `generate-ios-assets.sh`, `generate-android-icons.sh`
- **Bypass capacitor-assets**: Manual ImageMagick-based generation
- **Inconsistent outputs**: Different generation methods for each platform
### Configuration (Scattered)
- **`capacitor-assets.config.json`**: Basic configuration at root
- **Platform-specific configs**: Mixed in various build scripts
- **No validation**: No schema or consistency checks
## Target State
### Single Source of Truth
- **`resources/` directory**: Capacitor default location for source assets
- **Eliminate duplication**: Remove `assets/` directory after migration
- **Standardized paths**: All tools read from `resources/`
### Standardized Generation
- **`capacitor-assets`**: Single tool for all platform asset generation
- **Build-time generation**: Assets generated during build, not committed
- **Deterministic outputs**: Same inputs → same outputs every time
### Centralized Configuration
- **`config/assets/`**: All asset-related configuration files
- **Schema validation**: JSON schema for configuration validation
- **CI safeguards**: Automated validation and compliance checks
## Migration Steps
### Phase 1: Foundation Setup ✅
- [x] Create `config/assets/` directory structure
- [x] Create asset configuration schema (`schema.json`)
- [x] Create enhanced capacitor-assets configuration
- [x] Convert `capacitor.config.json` to `capacitor.config.ts`
- [x] Pin Node.js version (`.nvmrc`, `.node-version`)
- [x] Create dev-time asset configuration generator
- [x] Create asset configuration validator
- [x] Add npm scripts for asset management
- [x] Update `.gitignore` with proper asset exclusions
- [x] Create CI workflow for asset validation
### Phase 2: Validation & Testing
- [ ] Run `npm run assets:config` to generate new configuration
- [ ] Run `npm run assets:validate` to verify configuration
- [ ] Test `npm run build:native` workflow
- [ ] Verify CI workflow passes all checks
- [ ] Confirm no platform assets are committed to VCS
### Phase 3: Cleanup & Removal
- [ ] Remove `assets/` directory (after validation)
- [ ] Remove manual asset generation scripts
- [ ] Remove asset checking scripts
- [ ] Update documentation references
- [ ] Final validation of clean state
## Implementation Details
### File Structure
```
resources/ # Image sources ONLY
icon.png
splash.png
splash_dark.png
config/assets/ # Versioned config & schema
capacitor-assets.config.json
schema.json
scripts/
assets-config.js # Dev-time config generator
assets-validator.js # Schema validator
```
### Configuration Schema
The schema enforces:
- Source files must be in `resources/` directory
- Required fields for icon and splash sections
- Android adaptive icon support (foreground/background/monochrome)
- iOS LaunchScreen preferences
- Target directory validation
### CI Safeguards
- **Schema validation**: Configuration must comply with schema
- **Source file validation**: All referenced files must exist
- **Platform asset denial**: Reject commits with generated assets
- **Clean tree enforcement**: Build must not modify committed configs
## Testing Strategy
### Local Validation
```bash
# Generate configuration
npm run assets:config
# Validate configuration
npm run assets:validate
# Test build workflow
npm run build:native
# Clean generated assets
npm run assets:clean
```
### CI Validation
- **Asset validation workflow**: Runs on asset-related changes
- **Schema compliance**: Ensures configuration follows schema
- **Source file existence**: Verifies all referenced files exist
- **Platform asset detection**: Prevents committed generated assets
- **Build tree verification**: Ensures clean tree after build
## Risk Mitigation
### Data Loss Prevention
- **Backup branch**: Create backup before removing `assets/`
- **Validation checks**: Multiple validation steps before removal
- **Gradual migration**: Phase-by-phase approach with rollback capability
### Build Continuity
- **Per-platform scripts unchanged**: All existing build orchestration preserved
- **Standard toolchain**: Uses capacitor-assets, not custom scripts
- **Fallback support**: Manual scripts remain until migration complete
### Configuration Consistency
- **Schema enforcement**: JSON schema prevents invalid configurations
- **CI validation**: Automated checks catch configuration issues
- **Documentation updates**: Clear guidance for future changes
## Success Criteria
### Technical Requirements
- [ ] Single source of truth in `resources/` directory
- [ ] All platform assets generated via `capacitor-assets`
- [ ] No manual asset generation scripts
- [ ] Configuration validation passes all checks
- [ ] CI workflow enforces asset policies
### Quality Metrics
- [ ] Zero duplicate asset sources
- [ ] 100% configuration schema compliance
- [ ] No platform assets committed to VCS
- [ ] Clean build tree after asset generation
- [ ] Deterministic asset outputs
### User Experience
- [ ] Clear asset management documentation
- [ ] Simple development commands
- [ ] Consistent asset generation across platforms
- [ ] Reduced confusion about asset sources
## Next Steps
1. **Execute Phase 2**: Run validation and testing steps
2. **Verify CI workflow**: Ensure all checks pass
3. **Execute Phase 3**: Remove duplicate assets and scripts
4. **Update documentation**: Finalize README and BUILDING.md
5. **Team training**: Ensure all developers understand new workflow
## Rollback Plan
If issues arise during migration:
1. **Restore backup branch**: `git checkout backup-before-asset-migration`
2. **Revert configuration changes**: Remove new config files
3. **Restore manual scripts**: Re-enable previous asset generation
4. **Investigate issues**: Identify and resolve root causes
5. **Plan revised migration**: Adjust approach based on lessons learned
---
**Status**: Ready for Phase 2 execution
**Priority**: High
**Estimated Effort**: 2-3 hours
**Dependencies**: CI workflow validation
**Stakeholders**: Development team

View File

@@ -1,117 +0,0 @@
# Logging Configuration Guide
## Overview
TimeSafari now supports configurable logging levels via the `VITE_LOG_LEVEL` environment variable. This allows developers to control the verbosity of console output without modifying code.
## Available Log Levels
| Level | Value | Description | Console Output |
|-------|-------|-------------|----------------|
| `error` | 0 | Errors only | Critical errors only |
| `warn` | 1 | Warnings and errors | Warnings and errors |
| `info` | 2 | Info, warnings, and errors | General information, warnings, and errors |
| `debug` | 3 | All log levels | Verbose debugging information |
## Environment Variable
Set the `VITE_LOG_LEVEL` environment variable to control logging:
```bash
# Show only errors
VITE_LOG_LEVEL=error
# Show warnings and errors (default for production web)
VITE_LOG_LEVEL=warn
# Show info, warnings, and errors (default for development/capacitor)
VITE_LOG_LEVEL=info
# Show all log levels including debug
VITE_LOG_LEVEL=debug
```
## Default Behavior by Platform
The logger automatically selects appropriate default log levels based on your platform and environment:
- **Production Web**: `warn` (warnings and errors only)
- **Electron**: `error` (errors only - very quiet)
- **Development/Capacitor**: `info` (info and above)
## Usage Examples
### Setting Log Level in Development
```bash
# In your terminal before running the app
export VITE_LOG_LEVEL=debug
npm run dev
# Or inline
VITE_LOG_LEVEL=debug npm run dev
```
### Setting Log Level in Production
```bash
# For verbose production logging
VITE_LOG_LEVEL=info npm run build:web
# For minimal production logging
VITE_LOG_LEVEL=warn npm run build:web
```
### Programmatic Access
The logger provides methods to check current configuration:
```typescript
import { logger } from '@/utils/logger';
// Get current log level
const currentLevel = logger.getCurrentLevel(); // 'info'
// Check if a level is enabled
const debugEnabled = logger.isLevelEnabled('debug'); // false if level < debug
// Get available levels
const levels = logger.getAvailableLevels(); // ['error', 'warn', 'info', 'debug']
```
## Database Logging
Database logging continues to work regardless of console log level settings. All log messages are still stored in the database for debugging and audit purposes.
## Migration Notes
- **Existing code**: No changes required - logging behavior remains the same
- **New feature**: Use `VITE_LOG_LEVEL` to override default behavior
- **Backward compatible**: All existing logging calls work as before
## Best Practices
1. **Development**: Use `VITE_LOG_LEVEL=debug` for maximum visibility
2. **Testing**: Use `VITE_LOG_LEVEL=info` for balanced output
3. **Production**: Use `VITE_LOG_LEVEL=warn` for minimal noise
4. **Debugging**: Temporarily set `VITE_LOG_LEVEL=debug` to troubleshoot issues
## Troubleshooting
### No Logs Appearing
Check your `VITE_LOG_LEVEL` setting:
```bash
echo $VITE_LOG_LEVEL
```
### Too Many Logs
Reduce verbosity by setting a lower log level:
```bash
VITE_LOG_LEVEL=warn
```
### Platform-Specific Issues
Remember that Electron is very quiet by default. Use `VITE_LOG_LEVEL=info` to see more output in Electron builds.

View File

@@ -54,16 +54,14 @@ server {
}
# Handle API requests (if needed)
# Note: Backend API is not currently deployed
# Uncomment and configure when backend service is available
# location /api/ {
# limit_req zone=api burst=20 nodelay;
# proxy_pass http://backend:3000;
# proxy_set_header Host $host;
# proxy_set_header X-Real-IP $remote_addr;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto $scheme;
# }
location /api/ {
limit_req zone=api burst=20 nodelay;
proxy_pass http://backend:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Handle health check
location /health {

View File

@@ -9,10 +9,10 @@
# - Static file caching optimization
# - Security hardening
# user nginx; # Commented out - nginx runs as non-root user in container
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /tmp/nginx.pid; # Use /tmp for PID file to avoid permission issues
pid /var/run/nginx.pid;
events {
worker_connections 1024;

View File

@@ -54,16 +54,14 @@ server {
}
# Handle API requests (if needed)
# Note: Backend API is not currently deployed
# Uncomment and configure when backend service is available
# location /api/ {
# limit_req zone=api burst=20 nodelay;
# proxy_pass http://backend:3000;
# proxy_set_header Host $host;
# proxy_set_header X-Real-IP $remote_addr;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_set_header X-Forwarded-Proto $scheme;
# }
location /api/ {
limit_req zone=api burst=20 nodelay;
proxy_pass http://backend:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Handle health check
location /health {

View File

@@ -0,0 +1,422 @@
# Android Build Scripts Documentation
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: ✅ **COMPLETE** - Full Android build system integration
## Overview
The Android build system for TimeSafari has been integrated with the Vite
mode-based pattern, providing consistent environment management and flexible
build options across development, testing, and production environments.
**Note:** All Android builds should be invoked via `npm run build:android*` scripts for consistency. The legacy `build:capacitor:android*` scripts are now aliases for the corresponding `build:android*` scripts.
## Build Script Integration
### Package.json Scripts
The Android build system is fully integrated into `package.json` with the
following scripts:
#### Basic Build Commands
```bash
# Development builds (defaults to --mode development)
npm run build:android:dev # Development build
npm run build:android:test # Testing build
npm run build:android:prod # Production build
```
#### Build Type Commands
```bash
# Debug builds
npm run build:android:debug # Debug APK build
# Release builds
npm run build:android:release # Release APK build
```
#### Specialized Commands
```bash
# Android Studio integration
npm run build:android:studio # Build + open Android Studio
# Package builds
npm run build:android:apk # Build APK file
npm run build:android:aab # Build AAB (Android App Bundle)
# Utility commands
npm run build:android:clean # Clean build artifacts only
npm run build:android:sync # Sync Capacitor only
npm run build:android:assets # Generate assets only
```
#### Legacy Command
```bash
# Original script (maintains backward compatibility)
npm run build:android # Full build process
```
## Script Usage
### Direct Script Usage
The `build-android.sh` script supports comprehensive command-line options:
```bash
# Basic usage
./scripts/build-android.sh [options]
# Environment-specific builds
./scripts/build-android.sh --dev --studio # Development + open studio
./scripts/build-android.sh --test --apk # Testing APK build
./scripts/build-android.sh --prod --aab # Production AAB build
# Utility operations
./scripts/build-android.sh --clean # Clean only
./scripts/build-android.sh --sync # Sync only
./scripts/build-android.sh --assets # Assets only
```
### Command-Line Options
| Option | Description | Default |
|--------|-------------|---------|
| `--dev`, `--development` | Build for development environment | ✅ |
| `--test` | Build for testing environment | |
| `--prod`, `--production` | Build for production environment | |
| `--debug` | Build debug APK | ✅ |
| `--release` | Build release APK | |
| `--studio` | Open Android Studio after build | |
| `--apk` | Build APK file | |
| `--aab` | Build AAB (Android App Bundle) | |
| `--clean` | Clean build artifacts only | |
| `--sync` | Sync Capacitor only | |
| `--assets` | Generate assets only | |
| `-h`, `--help` | Show help message | |
| `-v`, `--verbose` | Enable verbose logging | |
## Build Process
### Complete Build Flow
1. **Resource Check**: Validate Android resources
2. **Cleanup**: Clean Android app and build artifacts
3. **Capacitor Build**: Build web assets with environment-specific mode
4. **Gradle Clean**: Clean Gradle build cache
5. **Gradle Build**: Assemble debug/release APK
6. **Capacitor Sync**: Sync web assets to Android platform
7. **Asset Generation**: Generate Android-specific assets
8. **Package Build**: Build APK/AAB if requested
9. **Studio Launch**: Open Android Studio if requested
### Environment-Specific Builds
#### Development Environment (`--dev`)
```bash
# Uses --mode development
npm run build:capacitor
# Builds with development optimizations and debugging enabled
```
#### Testing Environment (`--test`)
```bash
# Uses --mode test
npm run build:capacitor -- --mode test
# Builds with testing configurations and test API endpoints
```
#### Production Environment (`--prod`)
```bash
# Uses --mode production
npm run build:capacitor -- --mode production
# Builds with production optimizations and live API endpoints
```
## Build Artifacts
### APK Files
- **Debug APK**: `android/app/build/outputs/apk/debug/app-debug.apk`
- **Release APK**: `android/app/build/outputs/apk/release/app-release.apk`
### AAB Files
- **Release AAB**: `android/app/build/outputs/bundle/release/app-release.aab`
### Build Locations
```bash
# APK files
android/app/build/outputs/apk/debug/
android/app/build/outputs/apk/release/
# AAB files
android/app/build/outputs/bundle/release/
# Gradle build cache
android/app/build/
android/.gradle/
```
## Environment Variables
The build system automatically sets environment variables based on the build
type:
### Capacitor Environment
```bash
VITE_PLATFORM=capacitor
VITE_PWA_ENABLED=false
VITE_DISABLE_PWA=true
DEBUG_MIGRATIONS=0
```
### Git Integration
```bash
VITE_GIT_HASH=<git-commit-hash>
# Automatically set from current git commit
```
## Error Handling
### Exit Codes
| Code | Description |
|------|-------------|
| 1 | Android cleanup failed |
| 2 | Web build failed |
| 3 | Capacitor build failed |
| 4 | Gradle clean failed |
| 5 | Gradle assemble failed |
| 6 | Capacitor sync failed |
| 7 | Asset generation failed |
| 8 | Android Studio launch failed |
| 9 | Resource check failed |
### Common Issues
#### Resource Check Failures
```bash
# Resource check may find issues but continues build
log_warning "Resource check found issues, but continuing with build..."
```
#### Gradle Build Failures
```bash
# Check Android SDK and build tools
./android/gradlew --version
# Verify JAVA_HOME is set correctly
echo $JAVA_HOME
```
## Integration with Capacitor
### Capacitor Sync Process
```bash
# Full sync (all platforms)
npx cap sync
# Android-specific sync
npx cap sync android
```
### Asset Generation
```bash
# Generate Android-specific assets
npx capacitor-assets generate --android
```
### Android Studio Integration
```bash
# Open Android Studio with project
npx cap open android
```
## Development Workflow
### Typical Development Cycle
```bash
# 1. Make code changes
# 2. Build for development
npm run build:android:dev
# 3. Open Android Studio for debugging
npm run build:android:studio
# 4. Test on device/emulator
# 5. Iterate and repeat
```
### Testing Workflow
```bash
# 1. Build for testing environment
npm run build:android:test
# 2. Build test APK
npm run build:android:test -- --apk
# 3. Install and test on device
adb install android/app/build/outputs/apk/debug/app-debug.apk
```
### Production Workflow
```bash
# 1. Build for production environment
npm run build:android:prod
# 2. Build release AAB for Play Store
npm run build:android:prod -- --aab
# 3. Sign and upload to Play Console
```
## Performance Optimization
### Build Time Optimization
- **Incremental Builds**: Gradle caches build artifacts
- **Parallel Execution**: Multiple build steps run in parallel
- **Resource Optimization**: Assets are optimized for Android
### Memory Management
- **Gradle Daemon**: Reuses JVM for faster builds
- **Build Cache**: Caches compiled resources
- **Clean Builds**: Full cleanup when needed
## Troubleshooting
### Common Build Issues
#### Gradle Build Failures
```bash
# Clean Gradle cache
cd android && ./gradlew clean && cd ..
# Check Java version
java -version
# Verify Android SDK
echo $ANDROID_HOME
```
#### Capacitor Sync Issues
```bash
# Force full sync
npx cap sync android --force
# Check Capacitor configuration
cat capacitor.config.json
```
#### Asset Generation Issues
```bash
# Regenerate assets
npx capacitor-assets generate --android --force
# Check asset source files
ls -la src/assets/
```
### Debug Mode
```bash
# Enable verbose logging
./scripts/build-android.sh --verbose
# Show environment variables
./scripts/build-android.sh --env
```
## Best Practices
### Build Optimization
1. **Use Appropriate Environment**: Always specify the correct environment
2. **Clean When Needed**: Use `--clean` for troubleshooting
3. **Incremental Builds**: Avoid unnecessary full rebuilds
4. **Asset Management**: Keep assets optimized for mobile
### Development Workflow
1. **Development Builds**: Use `--dev` for daily development
2. **Testing Builds**: Use `--test` for QA testing
3. **Production Builds**: Use `--prod` for release builds
4. **Studio Integration**: Use `--studio` for debugging
### Error Prevention
1. **Resource Validation**: Always run resource checks
2. **Environment Consistency**: Use consistent environment variables
3. **Build Verification**: Test builds on actual devices
4. **Version Control**: Keep build scripts in version control
## Migration from Legacy System
### Backward Compatibility
The new system maintains full backward compatibility:
```bash
# Old command still works (now an alias)
npm run build:capacitor:android
# New commands provide more flexibility
npm run build:android:dev
npm run build:android:test
npm run build:android:prod
```
**Note:** All Android builds should use the `build:android*` pattern. The `build:capacitor:android*` scripts are provided as aliases for compatibility but will be deprecated in the future.
### Migration Checklist
- [ ] Update CI/CD pipelines to use new commands
- [ ] Update documentation references
- [ ] Train team on new build options
- [ ] Test all build environments
- [ ] Verify artifact locations
## Future Enhancements
### Planned Features
1. **Build Profiles**: Custom build configurations
2. **Automated Testing**: Integration with test suites
3. **Build Analytics**: Performance metrics and reporting
4. **Cloud Builds**: Remote build capabilities
### Integration Opportunities
1. **Fastlane Integration**: Automated deployment
2. **CI/CD Enhancement**: Pipeline optimization
3. **Monitoring**: Build performance tracking
4. **Documentation**: Auto-generated build reports
---
**Status**: Complete and ready for production use
**Last Updated**: 2025-07-11
**Version**: 1.0
**Maintainer**: Matthew Raymer

405
docs/auto-run-guide.md Normal file
View File

@@ -0,0 +1,405 @@
# Auto-Run Guide
**Author**: Matthew Raymer
**Date**: 2025-07-12
**Status**: 🎯 **ACTIVE** - In Use
## Overview
The TimeSafari auto-run system intelligently detects available devices and
automatically builds and launches the app on the best available target. It
supports Android devices/emulators, iOS devices/simulators, and Electron
desktop apps.
## Features
### Smart Device Detection
- **Android**: Detects real devices vs emulators using ADB
- **iOS**: Detects real devices vs simulators using xcrun
- **Electron**: Checks for Electron availability
- **Priority**: Real devices preferred over simulators/emulators
### Build Mode Support
- **Development**: Default mode for daily development
- **Test**: Optimized for testing with test data
- **Production**: Production-ready builds
### Platform Targeting
- **All platforms**: Automatically detects and runs on all available
- **Specific platform**: Target only iOS, Android, or Electron
- **Cross-platform**: Works on macOS, Linux, and Windows
### Auto-Run Options
- **Build + Auto-Run**: Single command to build and launch
- **Smart Detection**: Automatically chooses best available target
- **Error Handling**: Graceful fallbacks when devices unavailable
## Usage
### Auto-Run Script (Recommended)
```bash
# Auto-detect and run on all available platforms (development mode)
npm run auto-run
# Run in test mode
npm run auto-run:test
# Run in production mode
npm run auto-run:prod
# Target specific platforms
npm run auto-run:ios
npm run auto-run:android
npm run auto-run:electron
```
### Build Script Auto-Run
#### iOS Auto-Run Commands
```bash
# Test build + auto-run
npm run build:ios:test:run
# Production build + auto-run
npm run build:ios:prod:run
# Debug build + auto-run
npm run build:ios:debug:run
# Release build + auto-run
npm run build:ios:release:run
```
#### Android Auto-Run Commands
```bash
# Test build + auto-run
npm run build:android:test:run
# Production build + auto-run
npm run build:android:prod:run
# Debug build + auto-run
npm run build:android:debug:run
# Release build + auto-run
npm run build:android:release:run
```
#### Electron Auto-Run Commands
```bash
# Development build + auto-run
npm run build:electron:dev:run
# Test build + auto-run
npm run build:electron:test:run
# Production build + auto-run
npm run build:electron:prod:run
```
### Advanced Usage
```bash
# Direct script usage with options
./scripts/auto-run.sh --test --platform=ios
./scripts/auto-run.sh --prod --platform=android
./scripts/auto-run.sh --auto # Skip confirmation prompts
# Build script with auto-run flag
./scripts/build-ios.sh --test --auto-run
./scripts/build-android.sh --prod --auto-run
./scripts/build-electron.sh --test --auto-run
# Combine options
./scripts/auto-run.sh --test --platform=all --auto
```
### Command Line Options
| Option | Description | Example |
|--------|-------------|---------|
| `--test` | Build and run in test mode | `--test` |
| `--prod` | Build and run in production mode | `--prod` |
| `--platform=PLATFORM` | Target specific platform | `--platform=ios` |
| `--auto` | Skip confirmation prompts | `--auto` |
| `--auto-run` | Auto-run after build | `--auto-run` |
| `--help` | Show help message | `--help` |
**Platform Options:**
- `ios` - iOS devices/simulators only
- `android` - Android devices/emulators only
- `electron` - Electron desktop app only
- `all` - All available platforms (default)
## How It Works
### 1. Device Detection
**Android Detection:**
```bash
# Uses ADB to list devices
adb devices
# Parses output to distinguish:
# - Real devices: Physical Android phones/tablets
# - Emulators: Android emulator instances
```
**iOS Detection:**
```bash
# Uses xcrun to list devices
xcrun xctrace list devices
# Parses output to distinguish:
# - Real devices: Physical iPhones/iPads
# - Simulators: iOS Simulator instances
```
### 2. Build Process
The script automatically calls the appropriate build commands:
```bash
# Development mode
npm run build:ios:dev
npm run build:android:dev
npm run build:electron:dev
# Test mode
npm run build:ios:test
npm run build:android:test
npm run build:electron:test
# Production mode
npm run build:ios:prod
npm run build:android:prod
npm run build:electron:prod
```
### 3. Launch Process
**Android:**
- Real devices: Install APK and launch via ADB
- Emulators: Use `npx cap run android`
**iOS:**
- Real devices: Build release version (requires Xcode setup)
- Simulators: Use `npx cap run ios`
**Electron:**
- Launch via `npm run electron:start`
## Examples
### Development Workflow
```bash
# Quick development run
npm run auto-run
# Output:
# ✅ Found 1 real Android device: ABC123DEF456
# ✅ Found 1 iOS simulator: iPhone 15 Pro
# ✅ Electron: available
#
# Available targets:
# Android: real:ABC123DEF456
# iOS: simulator:iPhone 15 Pro
# Electron: available
#
# Continue with auto-run? (y/N): y
#
# 🔄 Building and running Android (real: ABC123DEF456)...
# 🔄 Building and running iOS (simulator: iPhone 15 Pro)...
# 🔄 Building and running Electron...
#
# ✅ Auto-run completed successfully! 3 platform(s) launched.
```
### Test Mode with Build Scripts
```bash
# iOS test build + auto-run
npm run build:ios:test:run
# Android test build + auto-run
npm run build:android:test:run
# Electron test build + auto-run
npm run build:electron:test:run
# Output:
# === TimeSafari iOS Build Process ===
# 🔄 Building Capacitor version (test)...
# 🔄 Syncing with Capacitor...
# 🔄 Building iOS app...
# 🔄 Auto-running iOS app...
# ✅ iOS app launched successfully!
# ✅ iOS build completed successfully!
```
### Production Mode
```bash
# Production build and run
npm run auto-run:prod
# Output:
# 🔄 Building Android (production)...
# 🔄 Building iOS (production)...
# 🔄 Building Electron (production)...
#
# ✅ Auto-run completed successfully! 3 platform(s) launched.
```
## Comparison: Auto-Run Script vs Build Scripts
### Auto-Run Script (`auto-run.sh`)
**Best for:**
- Multi-platform development
- Quick testing across devices
- Automated workflows
- CI/CD integration
**Features:**
- Smart device detection
- Multi-platform support
- Interactive confirmation
- Error recovery
### Build Scripts with `--auto-run`
**Best for:**
- Single platform development
- Specific build configurations
- Non-interactive workflows
- Build customization
**Features:**
- Platform-specific optimization
- Build customization options
- Direct control over build process
- Integration with existing workflows
## Troubleshooting
### Common Issues
**No devices detected:**
```bash
# Check Android devices
adb devices
# Check iOS devices (macOS only)
xcrun xctrace list devices
# Check Electron availability
which electron
```
**Build failures:**
```bash
# Clean and rebuild
npm run clean:android
npm run clean:ios
npm run clean:electron
# Then retry auto-run
npm run auto-run
```
**Permission issues:**
```bash
# Make script executable
chmod +x scripts/auto-run.sh
# Check ADB permissions (Android)
adb kill-server
adb start-server
```
### Platform-Specific Issues
**Android:**
- Ensure ADB is in PATH
- Enable USB debugging on device
- Accept device authorization prompt
- Check device is in "device" state (not "unauthorized")
**iOS:**
- Requires macOS with Xcode
- Ensure Xcode command line tools installed
- Check iOS Simulator is available
- For real devices: Requires proper certificates
**Electron:**
- Ensure Electron is installed globally or locally
- Check Node.js version compatibility
- Verify build dependencies are installed
### Debug Mode
Enable verbose logging by modifying the script:
```bash
# Add debug logging to auto-run.sh
set -x # Enable debug mode
```
## Integration with CI/CD
The auto-run script can be integrated into CI/CD pipelines:
```yaml
# Example GitHub Actions workflow
- name: Auto-run tests
run: |
npm run auto-run:test --auto
env:
# Set environment variables for CI
CI: true
```
## Best Practices
### Development Workflow
1. **Daily development**: Use `npm run auto-run` for quick testing
2. **Testing**: Use `npm run auto-run:test` before commits
3. **Production**: Use `npm run auto-run:prod` for final testing
4. **Single platform**: Use `npm run build:ios:test:run` for focused work
### Device Management
1. **Keep devices connected**: Reduces detection time
2. **Use consistent device names**: Helps with identification
3. **Regular cleanup**: Clear old builds and caches
### Performance Tips
1. **Use --auto flag**: Skip prompts in automated workflows
2. **Target specific platforms**: Use `--platform=ios` for faster runs
3. **Parallel execution**: Script runs platforms in sequence (can be optimized)
## Future Enhancements
### Planned Features
- **Parallel execution**: Run multiple platforms simultaneously
- **Device selection**: Choose specific devices when multiple available
- **Custom build configurations**: Support for custom build modes
- **Integration with IDEs**: VS Code and other IDE integration
- **Performance monitoring**: Track build and launch times
### Contributing
To add new features or fix issues:
1. Modify `scripts/auto-run.sh`
2. Update this documentation
3. Test on multiple platforms
4. Submit pull request
## Related Documentation
- [iOS Simulator Build and Icons](./ios-simulator-build-and-icons.md)
- [Android Build Guide](./android-build-guide.md)
- [Electron Build Guide](./electron-build-guide.md)
- [Testing Guide](./testing-guide.md)

View File

@@ -0,0 +1,616 @@
# Build Pattern Conversion Plan
**Author**: Matthew Raymer
**Date**: 2025-07-09
**Status**: **PLANNING** - Ready for Implementation
## Overview
Convert TimeSafari's build instruction pattern from the current script-based
approach to a new Vite `mode`-based pattern that provides better environment
management and consistency across all build targets.
## Why Vite Mode Instead of NODE_ENV?
### Vite's Native Mode System
Vite is designed to work with `mode`, which:
- Determines the `.env` file to load (e.g. `.env.production`, `.env.test`, etc.)
- Is passed to `defineConfig(({ mode }) => {...})` in `vite.config.ts`
- Is used to set behavior for dev/prod/test at config level
- Provides better integration with Vite's build system
### NODE_ENV Limitations
`NODE_ENV` is legacy from Webpack-era tooling:
- You can't change `NODE_ENV` manually and expect Vite to adapt
- Vite does not map `NODE_ENV` back to `mode`
- It's redundant with `mode` and might conflict with assumptions
- Limited integration with Vite's environment loading system
### Usage Pattern
```bash
# Correct: Use Vite's mode system
vite build --mode production
vite build --mode development
vite build --mode test
# Only if third-party libraries require NODE_ENV
NODE_ENV=production vite build --mode production
```
### Development vs Build Environments
**Development Environment:**
- **Build with defaults**: `npm run build:*` - Uses `--mode development` by default
- **Purpose**: Development builds for testing and debugging
- **Output**: Bundled files with development optimizations
**Testing/Production Environments:**
- **Build with explicit mode**: `npm run build:* -- --mode test/production`
- **Purpose**: Validate and deploy the bundled application
- **Output**: Optimized, bundled files for specific environment
### Mode Override Behavior
**How `--mode` Override Works:**
```bash
# Base script (no hardcoded mode)
"build:electron": "vite build --config vite.config.electron.mts"
# Development (uses Vite's default: --mode development)
npm run build:electron
# Executes: vite build --config vite.config.electron.mts
# Testing (explicitly overrides with --mode test)
npm run build:electron -- --mode test
# Executes: vite build --config vite.config.electron.mts --mode test
# Production (explicitly overrides with --mode production)
npm run build:electron -- --mode production
# Executes: vite build --config vite.config.electron.mts --mode production
```
**Key Points:**
- Base scripts have **no hardcoded `--mode`** to allow override
- `npm run build:electron` defaults to `--mode development`
- `npm run build:electron -- --mode test` overrides to `--mode test`
- Vite uses the **last `--mode` argument** if multiple are provided
### Capacitor Platform-Specific Commands
Capacitor requires platform-specific sync commands after building:
```bash
# General sync (copies web assets to all platforms)
npm run build:capacitor && npx cap sync
# Platform-specific sync
npm run build:capacitor && npx cap sync android
npm run build:capacitor && npx cap sync ios
# Environment-specific with platform sync
npm run build:capacitor -- --mode production && npx cap sync android
npm run build:capacitor -- --mode development && npx cap sync ios
```
### Docker Build Commands
Docker builds include both Vite asset generation and Docker image creation:
```bash
# General Docker build (Vite build + Docker image)
npm run build:web:docker
# Environment-specific Docker builds
npm run build:web:docker:test # Test environment + Docker image
npm run build:web:docker:prod # Production environment + Docker image
# Manual mode overrides for Docker builds
npm run build:web:docker -- --mode test
npm run build:web:docker -- --mode production
```
**Docker Build Process:**
1. **Vite Build**: Creates optimized web assets with environment-specific variables
2. **Docker Build**: Creates Docker image using `Dockerfile` in project root
3. **Image Tagging**: Images are tagged as `timesafari-web` for consistent management
**Key Features:**
- Complete end-to-end Docker workflow in single command
- Environment-aware builds (test/production configurations)
- Consistent image tagging for deployment
- Mode override flexibility for custom environments
### Electron Platform-Specific Commands
Electron requires platform-specific build commands after the Vite build:
```bash
# General Electron build (Vite build only)
npm run build:electron
# Platform-specific builds
npm run build:electron:windows # Windows executable
npm run build:electron:mac # macOS app bundle
npm run build:electron:linux # Linux executable
# Package-specific builds
npm run build:electron:appimage # Linux AppImage
npm run build:electron:dmg # macOS DMG installer
# Environment-specific builds
npm run build:electron -- --mode development
npm run build:electron -- --mode test
npm run build:electron -- --mode production
# Environment-specific with platform builds
npm run build:electron:windows -- --mode development
npm run build:electron:windows -- --mode test
npm run build:electron:windows -- --mode production
npm run build:electron:mac -- --mode development
npm run build:electron:mac -- --mode test
npm run build:electron:mac -- --mode production
npm run build:electron:linux -- --mode development
npm run build:electron:linux -- --mode test
npm run build:electron:linux -- --mode production
# Environment-specific with package builds
npm run build:electron:appimage -- --mode development
npm run build:electron:appimage -- --mode test
npm run build:electron:appimage -- --mode production
npm run build:electron:dmg -- --mode development
npm run build:electron:dmg -- --mode test
npm run build:electron:dmg -- --mode production
```
## Current State Analysis
### Existing Build Scripts
- **Web**: `build:web` - Uses vite.config.web.mts
- **Capacitor**: `build:capacitor` - Uses vite.config.capacitor.mts
- **Android**: `build:android` - Shell script wrapper
- **iOS**: `build:ios` - Shell script wrapper
- **Electron**: `build:electron` - Uses vite.config.electron.mts
- **Windows**: `build:electron:windows` - Windows executable
- **macOS**: `build:electron:mac` - macOS app bundle
- **Linux**: `build:electron:linux` - Linux executable
- **AppImage**: `build:electron:appimage` - Linux AppImage
- **DMG**: `build:electron:dmg` - macOS DMG installer
### Current `package.json` Scripts
```json
{
"build:capacitor": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode capacitor --config vite.config.capacitor.mts",
"build:web": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.web.mts",
"build:electron": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode electron --config vite.config.electron.mts"
}
```
## Target Pattern
### New Vite Mode-Based Pattern
```bash
# Development builds (defaults to --mode development)
npm run build:web-dev
npm run build:capacitor-dev
npm run build:electron-dev
# Testing builds (bundle required)
npm run build:web -- --mode test
npm run build:capacitor -- --mode test && npx cap sync
npm run build:electron -- --mode test
# Production builds (bundle required)
npm run build:web -- --mode production
npm run build:capacitor -- --mode production && npx cap sync
npm run build:electron -- --mode production
# Docker builds
npm run build:web:docker -- --mode test
npm run build:web:docker -- --mode production
# Docker environment-specific builds
npm run build:web:docker:test
npm run build:web:docker:prod
# Capacitor platform-specific builds
npm run build:capacitor:android -- --mode test
npm run build:capacitor:android -- --mode production
npm run build:capacitor:ios -- --mode test
npm run build:capacitor:ios -- --mode production
# Electron platform-specific builds
npm run build:electron:windows -- --mode test
npm run build:electron:windows -- --mode production
npm run build:electron:mac -- --mode test
npm run build:electron:mac -- --mode production
npm run build:electron:linux -- --mode test
npm run build:electron:linux -- --mode production
# Electron package-specific builds
npm run build:electron:appimage -- --mode test
npm run build:electron:appimage -- --mode production
npm run build:electron:dmg -- --mode test
npm run build:electron:dmg -- --mode production
```
### New `package.json` Scripts Structure
```json
{
"build:web": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite --mode development --config vite.config.web.mts",
"build:web:dev": "npm run build:web",
"build:web:build": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode development --config vite.config.web.mts",
"build:web:test": "npm run build:web:build -- --mode test",
"build:web:prod": "npm run build:web:build -- --mode production",
"build:web:docker": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.web.mts && docker build -t timesafari-web .",
"build:web:docker:test": "npm run build:web:docker -- --mode test",
"build:web:docker:prod": "npm run build:web:docker -- --mode production",
"build:capacitor": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode capacitor --config vite.config.capacitor.mts",
"build:capacitor-dev": "npm run build:capacitor",
"build:capacitor:sync": "npm run build:capacitor && npx cap sync",
"build:capacitor:android": "npm run build:capacitor:sync && npx cap sync android",
"build:capacitor:ios": "npm run build:capacitor:sync && npx cap sync ios",
"build:electron": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.electron.mts",
"build:electron:dev": "npm run build:electron && cd electron && npm run electron:start",
"build:electron:windows": "npm run build:electron && cd electron && npm run build:windows",
"build:electron:mac": "npm run build:electron && cd electron && npm run build:mac",
"build:electron:linux": "npm run build:electron && cd electron && npm run build:linux",
"build:electron:appimage": "npm run build:electron:linux && cd electron && npm run build:appimage",
"build:electron:dmg": "npm run build:electron:mac && cd electron && npm run build:dmg"
}
```
## Implementation Plan
### Phase 1: Environment Configuration (Day 1)
#### 1.1 Update Vite Configurations
- [ ] **vite.config.web.mts**: Add mode-based configuration
- [ ] **vite.config.capacitor.mts**: Add mode-based configuration
- [ ] **vite.config.electron.mts**: Add mode-based configuration
- [ ] **vite.config.common.mts**: Add environment-specific variables
#### 1.2 Environment Variables Setup
- [ ] Create `.env.development` file for development settings
- [ ] Create `.env.test` file for testing settings
- [ ] Create `.env.production` file for production settings
- [ ] Update `.env.example` with new pattern
#### 1.3 Environment Detection Logic
```typescript
// vite.config.common.mts
export default defineConfig(({ mode }) => {
const getEnvironmentConfig = (mode: string) => {
switch (mode) {
case 'production':
return { /* production settings */ };
case 'test':
return { /* testing settings */ };
default:
return { /* development settings */ };
}
};
return {
define: {
__DEV__: mode === 'development',
__TEST__: mode === 'test',
__PROD__: mode === 'production'
},
// ... other config
};
});
```
### Phase 2: Package.json Scripts Update (Day 1)
#### 2.1 Web Build Scripts
```json
{
"build:web": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.web.mts",
"build:web-dev": "npm run build:web",
"build:web-test": "npm run build:web -- --mode test",
"build:web-prod": "npm run build:web -- --mode production"
}
```
#### 2.2 Capacitor Build Scripts
```json
{
"build:capacitor": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --mode capacitor --config vite.config.capacitor.mts",
"build:capacitor-dev": "npm run build:capacitor",
"build:capacitor:sync": "npm run build:capacitor && npx cap sync",
"build:capacitor:android": "npm run build:capacitor:sync && npx cap sync android",
"build:capacitor:ios": "npm run build:capacitor:sync && npx cap sync ios",
"build:capacitor-test": "npm run build:capacitor -- --mode test && npx cap sync",
"build:capacitor-prod": "npm run build:capacitor -- --mode production && npx cap sync",
"build:capacitor:android-test": "npm run build:capacitor -- --mode test && npx cap sync android",
"build:capacitor:android-prod": "npm run build:capacitor -- --mode production && npx cap sync android",
"build:capacitor:ios-test": "npm run build:capacitor -- --mode test && npx cap sync ios",
"build:capacitor:ios-prod": "npm run build:capacitor -- --mode production && npx cap sync ios"
}
```
#### 2.3 Electron Build Scripts
```json
{
"build:electron": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.electron.mts",
"build:electron-dev": "npm run build:electron",
"build:electron:windows": "npm run build:electron && cd electron && npm run build:windows",
"build:electron:mac": "npm run build:electron && cd electron && npm run build:mac",
"build:electron:linux": "npm run build:electron && cd electron && npm run build:linux",
"build:electron:appimage": "npm run build:electron:linux && cd electron && npm run build:appimage",
"build:electron:dmg": "npm run build:electron:mac && cd electron && npm run build:dmg",
"build:electron-test": "npm run build:electron -- --mode test",
"build:electron-prod": "npm run build:electron -- --mode production",
"build:electron:windows-test": "npm run build:electron -- --mode test && cd electron && npm run build:windows",
"build:electron:windows-prod": "npm run build:electron -- --mode production && cd electron && npm run build:windows",
"build:electron:mac-dev": "npm run build:electron -- --mode development && cd electron && npm run build:mac",
"build:electron:mac-test": "npm run build:electron -- --mode test && cd electron && npm run build:mac",
"build:electron:mac-prod": "npm run build:electron -- --mode production && cd electron && npm run build:mac",
"build:electron:linux-test": "npm run build:electron -- --mode test && cd electron && npm run build:linux",
"build:electron:linux-prod": "npm run build:electron -- --mode production && cd electron && npm run build:linux"
}
```
#### 2.4 Docker Build Scripts
```json
{
"build:web:docker": "VITE_GIT_HASH=`git log -1 --pretty=format:%h` vite build --config vite.config.web.mts && docker build -t timesafari-web .",
"build:web:docker:test": "npm run build:web:docker -- --mode test",
"build:web:docker:prod": "npm run build:web:docker -- --mode production"
}
```
**Docker Build Features:**
- Complete Vite build + Docker image creation workflow
- Environment-specific configurations (test/production)
- Consistent image tagging (`timesafari-web`)
- Mode override flexibility for custom environments
### Phase 3: Shell Script Updates (Day 2)
#### 3.1 Update build-electron.sh
- [ ] Add mode-based environment support
- [ ] Update environment loading logic
- [ ] Add environment-specific build paths
- [ ] Update logging to show environment
#### 3.2 Update build-android.sh
- [ ] Add mode-based environment support
- [ ] Update environment detection
- [ ] Add environment-specific configurations
#### 3.3 Update build-ios.sh
- [ ] Add mode-based environment support
- [ ] Update environment detection
- [ ] Add environment-specific configurations
### Phase 4: Documentation Updates (Day 2)
#### 4.1 Update BUILDING.md
- [ ] Document new Vite mode-based pattern
- [ ] Update build instructions
- [ ] Add environment-specific examples
- [ ] Update troubleshooting section
#### 4.2 Update scripts/README.md
- [ ] Document new Vite mode-based build patterns
- [ ] Update usage examples
- [ ] Add environment configuration guide
#### 4.3 Update CI/CD Documentation
- [ ] Update GitHub Actions workflows
- [ ] Update Docker build instructions
- [ ] Update deployment guides
### Phase 5: Testing & Validation (Day 3)
#### 5.1 Environment Testing
- [ ] Test dev environment builds
- [ ] Test test environment builds
- [ ] Test prod environment builds
- [ ] Validate environment variables
#### 5.2 Platform Testing
- [ ] Test web builds across environments
- [ ] Test capacitor builds across environments
- [ ] Test capacitor android sync across environments
- [ ] Test capacitor ios sync across environments
- [ ] Test electron builds across environments
- [ ] Test electron windows builds across environments
- [ ] Test electron mac builds across environments
- [ ] Test electron linux builds across environments
- [ ] Test electron appimage builds across environments
- [ ] Test electron dmg builds across environments
- [ ] Test docker builds across environments
- [ ] Test docker image creation and tagging
- [ ] Test docker environment-specific configurations
#### 5.3 Integration Testing
- [ ] Test with existing CI/CD pipelines
- [ ] Test with existing deployment scripts
- [ ] Test with existing development workflows
## Environment-Specific Configurations
### Development Environment (--mode development)
```typescript
{
VITE_API_URL: 'http://localhost:3000',
VITE_DEBUG: 'true',
VITE_LOG_LEVEL: 'debug',
VITE_ENABLE_DEV_TOOLS: 'true'
}
```
### Testing Environment (--mode test)
```typescript
{
VITE_API_URL: 'https://test-api.timesafari.com',
VITE_DEBUG: 'false',
VITE_LOG_LEVEL: 'info',
VITE_ENABLE_DEV_TOOLS: 'false'
}
```
### Production Environment (--mode production)
```typescript
{
VITE_API_URL: 'https://api.timesafari.com',
VITE_DEBUG: 'false',
VITE_LOG_LEVEL: 'warn',
VITE_ENABLE_DEV_TOOLS: 'false'
}
```
## Migration Strategy
### Backward Compatibility
- [ ] Keep existing script names as aliases
- [ ] Add deprecation warnings for old scripts
- [ ] Maintain existing CI/CD compatibility
- [ ] Provide migration guide for users
### Gradual Rollout
1. **Week 1**: Implement new scripts alongside existing ones
2. **Week 2**: Update CI/CD to use new pattern
3. **Week 3**: Update documentation and guides
4. **Week 4**: Deprecate old scripts with warnings
## Success Metrics
### Technical Metrics
- [ ] All builds work with Vite mode-based pattern
- [ ] Environment variables properly loaded
- [ ] Build artifacts correctly generated
- [ ] No regression in existing functionality
### Process Metrics
- [ ] Reduced build script complexity
- [ ] Improved environment management
- [ ] Better developer experience
- [ ] Consistent build patterns
## Risk Assessment
### Low Risk
- [ ] Environment variable changes
- [ ] Package.json script updates
- [ ] Documentation updates
### Medium Risk
- [ ] Vite configuration changes (mode-based)
- [ ] Shell script modifications
- [ ] CI/CD pipeline updates
### High Risk
- [ ] Breaking existing build processes
- [ ] Environment-specific bugs
- [ ] Deployment failures
## Rollback Plan
### Immediate Rollback
- [ ] Revert package.json changes
- [ ] Restore original vite configs
- [ ] Restore original shell scripts
### Gradual Rollback
- [ ] Keep old scripts as primary
- [ ] Use new scripts as experimental
- [ ] Gather feedback before full migration
## Timeline
### Day 1: Foundation
- [ ] Environment configuration setup
- [ ] Package.json script updates
- [ ] Basic testing
### Day 2: Integration
- [ ] Shell script updates
- [ ] Documentation updates
- [ ] Integration testing
### Day 3: Validation
- [ ] Comprehensive testing
- [ ] Performance validation
- [ ] Documentation review
### Day 4: Deployment
- [ ] CI/CD updates
- [ ] Production validation
- [ ] User communication
## Next Steps
1. **Review and approve plan**
2. **Set up development environment**
3. **Begin Phase 1 implementation**
4. **Create test cases**
5. **Start implementation**
---
**Status**: Ready for implementation
**Priority**: Medium
**Estimated Effort**: 3-4 days
**Dependencies**: None
**Stakeholders**: Development team, DevOps team

View File

@@ -0,0 +1,470 @@
# TimeSafari Build Systems Overview
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: ✅ **COMPLETE** - All build systems documented and integrated
## Overview
TimeSafari supports multiple platforms and build targets through a unified build system architecture. This document provides a comprehensive overview of all build systems, their purposes, and how they work together.
## Build System Architecture
### Platform Support Matrix
| Platform | Build Script | Development | Testing | Production | Package Types |
|----------|--------------|-------------|---------|------------|---------------|
| **Web** | `build-web.sh` | ✅ Dev Server | ✅ Test Build | ✅ Prod Build | Docker Images |
| **Android** | `build-android.sh` | ✅ Debug APK | ✅ Test APK | ✅ Release APK/AAB | APK, AAB |
| **iOS** | `build-ios.sh` | ✅ Debug App | ✅ Test App | ✅ Release App | IPA |
| **Electron** | `build-electron.sh` | ✅ Dev App | ✅ Test App | ✅ Prod App | AppImage, DEB, DMG, EXE |
### Build Script Locations
```bash
scripts/
├── build-web.sh # Web/PWA builds
├── build-android.sh # Android mobile builds
├── build-ios.sh # iOS mobile builds (future)
├── build-electron.sh # Desktop builds
└── common.sh # Shared build utilities
```
## Unified Build Pattern
All build scripts follow a consistent pattern:
### 1. **Environment Setup**
```bash
# Set platform-specific environment variables
VITE_PLATFORM=<platform>
PWA: automatically enabled for web platforms
VITE_GIT_HASH=<git-commit-hash>
```
### 2. **Argument Parsing**
```bash
# Consistent command-line interface
./scripts/build-<platform>.sh [--dev|--test|--prod] [options]
```
### 3. **Build Process**
```bash
# Standard build flow
1. Validate environment
2. Clean build artifacts
3. Build web assets (Vite)
4. Platform-specific build
5. Generate assets
6. Create packages (if requested)
```
### 4. **Error Handling**
```bash
# Consistent exit codes
1: Cleanup failed
2: Web build failed
3: Platform build failed
4: Asset generation failed
5: Package creation failed
```
## Web Build System
### Purpose
Builds the web application for browser and PWA deployment.
### Key Features
- **Development Server**: Hot reload with Vite
- **PWA Support**: Service workers and manifest generation
- **Docker Integration**: Containerized deployment
- **Environment Modes**: Development, test, production
### Usage Examples
```bash
# Development (starts dev server)
npm run build:web:dev
# Production build
npm run build:web:prod
# Docker deployment
npm run build:web:docker:prod
```
### Output
- **Development**: Vite dev server at http://localhost:8080
- **Production**: Static files in `dist/` directory
- **Docker**: Containerized application image
**Documentation**: [Web Build Scripts Guide](build-web-script-integration.md)
## Android Build System
### Purpose
Builds Android mobile applications using Capacitor and Gradle.
### Key Features
- **Capacitor Integration**: Web-to-native bridge
- **Gradle Builds**: APK and AAB generation
- **Asset Generation**: Icons and splash screens
- **Device Deployment**: Direct APK installation
### Usage Examples
```bash
# Development build
npm run build:android:dev
# Production APK
npm run build:android:prod
# Deploy to device
npm run build:android:deploy
```
### Output
- **Debug APK**: `android/app/build/outputs/apk/debug/app-debug.apk`
- **Release APK**: `android/app/build/outputs/apk/release/app-release.apk`
- **AAB Bundle**: `android/app/build/outputs/bundle/release/app-release.aab`
### Device Deployment
```bash
# Automatic deployment to connected device
npm run build:android:deploy
# Manual deployment
adb install -r android/app/build/outputs/apk/debug/app-debug.apk
```
**Documentation**: [Android Build Scripts Guide](android-build-scripts.md)
## iOS Build System
### Purpose
Builds iOS mobile applications using Capacitor and Xcode.
### Key Features
- **Capacitor Integration**: Web-to-native bridge
- **Xcode Integration**: Native iOS builds
- **Asset Generation**: Icons and splash screens
- **Simulator Support**: iOS simulator testing
### Usage Examples
```bash
# Development build
npm run build:ios:dev
# Production build
npm run build:ios:prod
# Open Xcode
npm run build:ios:studio
```
### Output
- **Debug App**: `ios/App/build/Debug-iphonesimulator/App.app`
- **Release App**: `ios/App/build/Release-iphoneos/App.app`
- **IPA Package**: `ios/App/build/Release-iphoneos/App.ipa`
**Documentation**: [iOS Build Scripts Guide](ios-build-scripts.md) *(Future)*
## Electron Build System
### Purpose
Builds desktop applications for Windows, macOS, and Linux.
### Key Features
- **Cross-Platform**: Windows, macOS, Linux support
- **Package Formats**: AppImage, DEB, DMG, EXE
- **Development Mode**: Direct app execution
- **Single Instance**: Prevents multiple app instances
### Usage Examples
```bash
# Development (runs app directly)
npm run build:electron:dev
# Production AppImage
npm run build:electron:appimage:prod
# Production DMG
npm run build:electron:dmg:prod
```
### Output
- **Development**: App runs directly (no files created)
- **Packages**: Executables in `electron/dist/` directory
- **AppImage**: `TimeSafari-1.0.3-beta.AppImage`
- **DEB**: `TimeSafari_1.0.3-beta_amd64.deb`
- **DMG**: `TimeSafari-1.0.3-beta.dmg`
- **EXE**: `TimeSafari Setup 1.0.3-beta.exe`
**Documentation**: [Electron Build Scripts Guide](electron-build-scripts.md)
## Environment Management
### Environment Variables
All build systems use consistent environment variable patterns:
```bash
# Platform identification
VITE_PLATFORM=web|capacitor|electron
# PWA configuration
PWA: automatically enabled for web platforms
# Build information
VITE_GIT_HASH=<git-commit-hash>
DEBUG_MIGRATIONS=0|1
```
### Environment Files
```bash
.env.development # Development environment
.env.test # Testing environment
.env.production # Production environment
```
### Mode-Specific Configuration
Each build mode loads appropriate environment configuration:
- **Development**: Local development settings
- **Test**: Testing environment with test APIs
- **Production**: Production environment with live APIs
## Package.json Integration
### Script Organization
All build scripts are integrated into `package.json` with consistent naming:
```json
{
"scripts": {
// Web builds
"build:web": "./scripts/build-web.sh",
"build:web:dev": "./scripts/build-web.sh --dev",
"build:web:test": "./scripts/build-web.sh --test",
"build:web:prod": "./scripts/build-web.sh --prod",
// Android builds
"build:android": "./scripts/build-android.sh",
"build:android:dev": "./scripts/build-android.sh --dev",
"build:android:test": "./scripts/build-android.sh --test",
"build:android:prod": "./scripts/build-android.sh --prod",
// iOS builds
"build:ios": "./scripts/build-ios.sh",
"build:ios:dev": "./scripts/build-ios.sh --dev",
"build:ios:test": "./scripts/build-ios.sh --test",
"build:ios:prod": "./scripts/build-ios.sh --prod",
// Electron builds
"build:electron:dev": "./scripts/build-electron.sh --dev",
"build:electron:test": "./scripts/build-electron.sh --test",
"build:electron:prod": "./scripts/build-electron.sh --prod"
}
}
```
### Legacy Compatibility
Legacy scripts are maintained as aliases for backward compatibility:
```json
{
"scripts": {
// Legacy Android scripts (aliases)
"build:capacitor:android": "npm run build:android",
"build:capacitor:android:dev": "npm run build:android:dev",
"build:capacitor:android:test": "npm run build:android:test",
"build:capacitor:android:prod": "npm run build:android:prod"
}
}
```
## Build Artifacts
### Common Artifacts
All build systems generate consistent artifacts:
```bash
dist/ # Web build output
├── index.html # Main HTML file
├── assets/ # Compiled assets
├── manifest.webmanifest # PWA manifest
└── sw.js # Service worker
android/app/build/ # Android build output
├── outputs/apk/debug/ # Debug APKs
├── outputs/apk/release/ # Release APKs
└── outputs/bundle/release/ # AAB bundles
ios/App/build/ # iOS build output
├── Debug-iphonesimulator/ # Debug builds
└── Release-iphoneos/ # Release builds
electron/dist/ # Electron packages
├── *.AppImage # Linux AppImages
├── *.deb # Linux DEB packages
├── *.dmg # macOS DMG packages
└── *.exe # Windows installers
```
### Asset Generation
All platforms generate platform-specific assets:
```bash
# Icons and splash screens
npx capacitor-assets generate --android
npx capacitor-assets generate --ios
# PWA assets
npx vite build --config vite.config.web.mts
```
## Development Workflow
### Daily Development
```bash
# Web development
npm run build:web:dev # Starts dev server
# Android development
npm run build:android:dev # Builds debug APK
npm run build:android:deploy # Deploy to device
# Electron development
npm run build:electron:dev # Runs app directly
```
### Testing Workflow
```bash
# Test all platforms
npm run build:web:test
npm run build:android:test
npm run build:ios:test
npm run build:electron:test
```
### Production Workflow
```bash
# Build all platforms for production
npm run build:web:prod
npm run build:android:prod
npm run build:ios:prod
npm run build:electron:prod
# Create distribution packages
npm run build:electron:appimage:prod
npm run build:electron:dmg:prod
npm run build:electron:deb:prod
```
## Troubleshooting
### Common Issues
#### Build Failures
```bash
# Clean all build artifacts
npm run clean:all
# Rebuild from scratch
npm run build:<platform>:dev
```
#### Device Connection Issues
```bash
# Check Android device connection
adb devices
# Check iOS device connection
xcrun devicectl list devices
```
#### Environment Issues
```bash
# Verify environment variables
echo $VITE_PLATFORM
echo "PWA: automatically enabled for web platforms"
# Check environment files
ls -la .env*
```
### Debug Mode
Enable verbose logging for all build scripts:
```bash
# Verbose mode
./scripts/build-<platform>.sh --verbose
# Debug environment
DEBUG_MIGRATIONS=1 npm run build:<platform>:dev
```
## Performance Metrics
### Build Times (Typical)
| Platform | Development | Production | Package |
|----------|-------------|------------|---------|
| **Web** | 350ms | 8s | 12s |
| **Android** | 45s | 60s | 75s |
| **iOS** | 60s | 90s | 120s |
| **Electron** | 15s | 25s | 45s |
### Optimization Features
- **Incremental Builds**: Only rebuild changed files
- **Parallel Processing**: Multi-core build optimization
- **Caching**: Build artifact caching
- **Asset Optimization**: Image and code minification
## Security Considerations
### Build Security
- **Environment Isolation**: Separate dev/test/prod environments
- **Secret Management**: Secure handling of API keys
- **Code Signing**: Digital signatures for packages
- **Dependency Scanning**: Regular security audits
### Distribution Security
- **Package Verification**: Checksum validation
- **Code Signing**: Digital certificates for packages
- **Update Security**: Secure update mechanisms
- **Sandboxing**: Platform-specific security isolation
## Future Enhancements
### Planned Improvements
- **CI/CD Integration**: Automated build pipelines
- **Cross-Platform Testing**: Unified test framework
- **Performance Monitoring**: Build performance tracking
- **Asset Optimization**: Advanced image and code optimization
### Platform Expansion
- **Windows Store**: Microsoft Store packages
- **Mac App Store**: App Store distribution
- **Google Play**: Play Store optimization
- **App Store**: iOS App Store distribution
---
**Last Updated**: 2025-07-11
**Version**: 1.0.3-beta
**Status**: Production Ready

View File

@@ -0,0 +1,722 @@
# Build Systems Troubleshooting Guide
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: ✅ **COMPLETE** - Comprehensive troubleshooting for all build systems
## Overview
This guide provides comprehensive troubleshooting for all TimeSafari build systems, including common issues, solutions, and debugging techniques for web, Android, iOS, and Electron builds.
## Quick Diagnostic Commands
### Environment Check
```bash
# Check Node.js and npm versions
node --version
npm --version
# Check platform-specific tools
npx cap --version
npx vite --version
# Check environment variables
echo $VITE_PLATFORM
echo "PWA: automatically enabled for web platforms"
```
### Build System Status
```bash
# Check all build scripts exist
ls -la scripts/build-*.sh
# Check package.json scripts
npm run | grep build:
# Check build artifacts
ls -la dist/
ls -la android/app/build/
ls -la electron/dist/
```
## Web Build Issues
### Development Server Problems
#### Port Already in Use
```bash
# Check what's using port 8080
lsof -i :8080
# Kill the process
kill -9 <PID>
# Or use different port
npm run build:web:dev -- --port 8081
```
#### Hot Reload Not Working
```bash
# Clear browser cache
# DevTools > Application > Storage > Clear site data
# Restart dev server
npm run build:web:dev
# Check file watching
# Ensure no file system watcher limits
```
#### PWA Issues in Development
```bash
# Clear service worker
# DevTools > Application > Service Workers > Unregister
# Clear browser cache
# DevTools > Application > Storage > Clear site data
# Restart development server
npm run build:web:dev
```
### Production Build Issues
#### Build Fails with Errors
```bash
# Clean build artifacts
rm -rf dist/
# Clear npm cache
npm cache clean --force
# Reinstall dependencies
rm -rf node_modules/
npm install
# Rebuild
npm run build:web:prod
```
#### Large Bundle Size
```bash
# Analyze bundle
npm run build:web:prod
# Check dist/assets/ for large files
# Enable bundle analysis
npm install --save-dev vite-bundle-analyzer
# Add to vite.config.web.mts
```
#### PWA Not Working in Production
```bash
# Check manifest generation
ls -la dist/manifest.webmanifest
# Check service worker
ls -la dist/sw.js
# Verify HTTPS (required for PWA)
# Ensure site is served over HTTPS
```
### Docker Build Issues
#### Docker Build Fails
```bash
# Check Docker is running
docker --version
docker ps
# Clean Docker cache
docker system prune -a
# Rebuild without cache
docker build --no-cache -t timesafari-web:production .
```
#### Docker Image Too Large
```bash
# Use multi-stage builds
# Optimize base images
# Remove unnecessary files
# Analyze image layers
docker history timesafari-web:production
```
## Android Build Issues
### Build Process Failures
#### Gradle Build Fails
```bash
# Clean Gradle cache
cd android && ./gradlew clean && cd ..
# Clear Android build cache
rm -rf android/app/build/
rm -rf android/.gradle/
# Rebuild
npm run build:android:dev
```
#### Capacitor Sync Issues
```bash
# Clean Capacitor
npx cap clean android
# Reinstall Android platform
npx cap remove android
npx cap add android
# Sync manually
npx cap sync android
```
#### Resource Generation Fails
```bash
# Check source assets
ls -la assets/icon.png
ls -la assets/splash.png
# Regenerate assets
npx capacitor-assets generate --android
# Check generated resources
ls -la android/app/src/main/res/
```
### Device Deployment Issues
#### No Device Connected
```bash
# Check device connection
adb devices
# Enable USB debugging
# Settings > Developer options > USB debugging
# Install ADB drivers (Windows)
# Download from Google USB drivers
```
#### Device Unauthorized
```bash
# Check device for authorization dialog
# Tap "Allow USB debugging"
# Reset ADB
adb kill-server
adb start-server
# Check device again
adb devices
```
#### APK Installation Fails
```bash
# Uninstall existing app
adb uninstall app.timesafari.app
# Install fresh APK
adb install -r android/app/build/outputs/apk/debug/app-debug.apk
# Check installation
adb shell pm list packages | grep timesafari
```
### Performance Issues
#### Slow Build Times
```bash
# Enable Gradle daemon
# Add to ~/.gradle/gradle.properties:
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.configureondemand=true
# Use incremental builds
# Only rebuild changed files
```
#### Large APK Size
```bash
# Enable APK splitting
# Add to android/app/build.gradle:
android {
splits {
abi {
enable true
reset()
include 'x86', 'x86_64', 'arm64-v8a', 'armeabi-v7a'
}
}
}
```
## Electron Build Issues
### Development Issues
#### App Won't Start
```bash
# Check Electron installation
npm list electron
# Clear Electron cache
rm -rf ~/.config/TimeSafari/
rm -rf ~/Library/Application\ Support/TimeSafari/
rm -rf %APPDATA%\TimeSafari
# Reinstall Electron
npm install electron
```
#### Single Instance Lock Issues
```bash
# Check lock file
ls -la ~/.timesafari-lock
# Remove lock file manually
rm -f ~/.timesafari-lock
# Restart app
npm run build:electron:dev
```
#### Database Issues
```bash
# Clear database
./scripts/clear-database.sh
# Check database files
ls -la ~/.config/TimeSafari/
ls -la ~/Library/Application\ Support/TimeSafari/
# Rebuild database
npm run build:electron:dev
```
### Package Build Issues
#### Package Creation Fails
```bash
# Check electron-builder
npm list electron-builder
# Clean package cache
rm -rf electron/dist/
rm -rf electron/node_modules/
# Reinstall dependencies
cd electron && npm install && cd ..
# Rebuild package
npm run build:electron:appimage:prod
```
#### Code Signing Issues
```bash
# Check certificates
# macOS: Keychain Access
# Windows: Certificate Manager
# Linux: Check certificate files
# Skip code signing for testing
# Add to electron-builder.config.json:
"forceCodeSigning": false
```
#### Platform-Specific Issues
##### Linux AppImage Issues
```bash
# Check AppImage creation
file electron/dist/*.AppImage
# Make executable
chmod +x electron/dist/*.AppImage
# Test AppImage
./electron/dist/*.AppImage
```
##### macOS DMG Issues
```bash
# Check DMG creation
file electron/dist/*.dmg
# Mount DMG
hdiutil attach electron/dist/*.dmg
# Check contents
ls -la /Volumes/TimeSafari/
```
##### Windows EXE Issues
```bash
# Check EXE creation
file electron/dist/*.exe
# Test installer
# Run the EXE file
# Check installation directory
```
## iOS Build Issues (Future)
### Xcode Issues
```bash
# Check Xcode installation
xcode-select --print-path
# Install command line tools
xcode-select --install
# Accept Xcode license
sudo xcodebuild -license accept
```
### Simulator Issues
```bash
# List available simulators
xcrun simctl list devices
# Boot simulator
xcrun simctl boot "iPhone 15 Pro"
# Reset simulator
xcrun simctl erase all
```
### Code Signing Issues
```bash
# Check certificates
security find-identity -v -p codesigning
# Check provisioning profiles
ls ~/Library/MobileDevice/Provisioning\ Profiles/
# Install certificate
# Use Keychain Access or Xcode
```
## Environment Issues
### Environment Variables
#### Missing Environment Variables
```bash
# Check environment files
ls -la .env*
# Set required variables
export VITE_PLATFORM=web
# Check in build script
echo $VITE_PLATFORM
echo "PWA: automatically enabled for web platforms"
```
#### Wrong Environment Loaded
```bash
# Check current environment
echo $NODE_ENV
# Force environment
NODE_ENV=production npm run build:web:prod
# Check environment file loading
# Verify .env.production exists
```
### Dependency Issues
#### Missing Dependencies
```bash
# Check package.json
cat package.json | grep -A 10 "dependencies"
# Install missing dependencies
npm install
# Check for peer dependencies
npm ls
```
#### Version Conflicts
```bash
# Check for conflicts
npm ls
# Update dependencies
npm update
# Force resolution
npm install --force
```
#### Platform-Specific Dependencies
```bash
# Check Capacitor plugins
npx cap ls
# Install missing plugins
npm install @capacitor/core @capacitor/cli
# Sync plugins
npx cap sync
```
## Performance Issues
### Build Performance
#### Slow Build Times
```bash
# Enable parallel processing
# Add to package.json scripts:
"build:parallel": "npm run build:web:prod & npm run build:android:prod & wait"
# Use incremental builds
# Only rebuild changed files
# Optimize file watching
# Increase file watcher limits
```
#### Memory Issues
```bash
# Increase Node.js memory
NODE_OPTIONS="--max-old-space-size=4096" npm run build:web:prod
# Check memory usage
top -p $(pgrep node)
# Optimize build process
# Use streaming builds
# Minimize memory usage
```
### Runtime Performance
#### App Performance Issues
```bash
# Profile application
# Use browser DevTools > Performance
# Use React/Vue DevTools
# Check bundle size
npm run build:web:prod
# Analyze dist/assets/
# Optimize code splitting
# Implement lazy loading
```
## Debugging Techniques
### Verbose Logging
#### Enable Verbose Mode
```bash
# Web builds
./scripts/build-web.sh --verbose
# Android builds
./scripts/build-android.sh --verbose
# Electron builds
./scripts/build-electron.sh --verbose
```
#### Debug Environment
```bash
# Enable debug logging
DEBUG_MIGRATIONS=1 npm run build:web:dev
# Check debug output
# Look for detailed error messages
# Check console output
```
### Log Analysis
#### Build Logs
```bash
# Capture build logs
npm run build:web:prod > build.log 2>&1
# Analyze logs
grep -i error build.log
grep -i warning build.log
# Check for specific issues
grep -i "failed\|error\|exception" build.log
```
#### Runtime Logs
##### Web Browser
```bash
# Open DevTools
# Console tab for JavaScript errors
# Network tab for API issues
# Application tab for storage issues
```
##### Android
```bash
# View Android logs
adb logcat | grep -i timesafari
# Filter by app
adb logcat | grep -i "app.timesafari.app"
```
##### Electron
```bash
# View Electron logs
# Check console output
# Check DevTools console
# Check main process logs
```
## Common Error Messages
### Web Build Errors
#### "Module not found"
```bash
# Check import paths
# Verify file exists
# Check case sensitivity
# Update import statements
```
#### "Port already in use"
```bash
# Kill existing process
lsof -i :8080
kill -9 <PID>
# Use different port
npm run build:web:dev -- --port 8081
```
### Android Build Errors
#### "Gradle build failed"
```bash
# Clean Gradle cache
cd android && ./gradlew clean && cd ..
# Check Gradle version
./android/gradlew --version
# Update Gradle wrapper
cd android && ./gradlew wrapper --gradle-version 8.13 && cd ..
```
#### "Device not found"
```bash
# Check device connection
adb devices
# Enable USB debugging
# Settings > Developer options > USB debugging
# Install drivers (Windows)
# Download Google USB drivers
```
### Electron Build Errors
#### "App already running"
```bash
# Remove lock file
rm -f ~/.timesafari-lock
# Kill existing processes
pkill -f "TimeSafari"
# Restart app
npm run build:electron:dev
```
#### "Code signing failed"
```bash
# Check certificates
# macOS: Keychain Access
# Windows: Certificate Manager
# Skip code signing for testing
# Add to electron-builder.config.json:
"forceCodeSigning": false
```
## Prevention Strategies
### Best Practices
#### Regular Maintenance
```bash
# Update dependencies regularly
npm update
# Clean build artifacts
npm run clean:all
# Check for security vulnerabilities
npm audit
# Update build tools
npm update -g @capacitor/cli
npm update -g electron-builder
```
#### Environment Management
```bash
# Use consistent environments
# Separate dev/test/prod configurations
# Version control environment files
# Document environment requirements
```
#### Testing
```bash
# Test builds regularly
npm run build:web:prod
npm run build:android:prod
npm run build:electron:prod
# Test on different platforms
# Verify all features work
# Check performance metrics
```
### Monitoring
#### Build Monitoring
```bash
# Track build times
# Monitor build success rates
# Check for performance regressions
# Monitor bundle sizes
```
#### Runtime Monitoring
```bash
# Monitor app performance
# Track error rates
# Monitor user experience
# Check platform-specific issues
```
---
**Last Updated**: 2025-07-11
**Version**: 1.0.3-beta
**Status**: Production Ready

View File

@@ -0,0 +1,363 @@
# Build Web Script Integration
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: ✅ **COMPLETE** - Successfully implemented and tested
## Overview
The `build-web.sh` script has been successfully integrated into the TimeSafari build system, providing a unified approach to web builds that eliminates the need for multiple commands with flags in npm scripts.
## Problem Solved
### Previous Issue: Multiple Commands with Flags
The original package.json scripts had complex command chains that made debugging and maintenance difficult:
```json
// OLD PATTERN - Multiple commands with flags
"build:web:test": "npm run build:web:build -- --mode test",
"build:web:prod": "npm run build:web:build -- --mode production",
"build:web:docker:test": "npm run build:web:docker -- --mode test",
"build:web:docker:prod": "npm run build:web:docker -- --mode production"
```
### New Solution: Single Script with Arguments
The new approach uses a single shell script that handles all build modes and options:
```json
// NEW PATTERN - Single script calls
"build:web": "./scripts/build-web.sh",
"build:web:dev": "./scripts/build-web.sh --dev",
"build:web:test": "./scripts/build-web.sh --test",
"build:web:prod": "./scripts/build-web.sh --prod",
"build:web:docker": "./scripts/build-web.sh --docker",
"build:web:docker:test": "./scripts/build-web.sh --docker:test",
"build:web:docker:prod": "./scripts/build-web.sh --docker:prod",
"build:web:serve": "./scripts/build-web.sh --serve"
```
## Script Architecture
### Design Principles
1. **Single Responsibility**: Each npm script calls exactly one command
2. **Argument Parsing**: All complexity handled within the shell script
3. **Consistent Interface**: Follows the same pattern as other build scripts
4. **Environment Management**: Proper environment variable handling
5. **Error Handling**: Comprehensive error checking and reporting
6. **Development-First**: Development mode starts dev server instead of building
### Script Structure
```bash
#!/bin/bash
# build-web.sh
# Author: Matthew Raymer
# Description: Web build script for TimeSafari application
# Exit on any error
set -e
# Source common utilities
source "$(dirname "$0")/common.sh"
# Parse arguments and set build mode
parse_web_args "$@"
# Validate environment
validate_web_environment
# Setup environment
setup_build_env "web"
setup_web_environment
# Execute build steps
clean_build_artifacts "dist"
execute_vite_build "$BUILD_MODE"
# Optional steps
if [ "$DOCKER_BUILD" = true ]; then
execute_docker_build "$BUILD_MODE"
fi
if [ "$SERVE_BUILD" = true ]; then
serve_build
fi
```
## Build Modes Supported
### Development Mode (Default)
```bash
./scripts/build-web.sh
./scripts/build-web.sh --dev
```
- Starts Vite development server with hot reload
- No build step - runs development server directly
- Fast startup with live reload capabilities
- Available at http://localhost:8080
- **Source maps enabled** for debugging
- **PWA enabled** for development testing
### Test Mode
```bash
./scripts/build-web.sh --test
```
- Test environment configuration
- Minimal minification
- Source maps enabled
- Uses `.env.test` file
- **PWA enabled** for testing
### Production Mode
```bash
./scripts/build-web.sh --prod
```
- Full production optimizations
- Maximum minification
- Source maps disabled
- Uses `.env.production` file
- **PWA enabled** with full caching strategies
## Docker Integration
### Docker Build Options
```bash
# Development + Docker
./scripts/build-web.sh --docker
# Test + Docker
./scripts/build-web.sh --docker:test
# Production + Docker
./scripts/build-web.sh --docker:prod
```
### Docker Features
- Automatic image tagging (`timesafari-web:mode`)
- Build argument passing
- Environment-specific configurations
- Consistent image naming
## Local Development
### Development Server
```bash
./scripts/build-web.sh
./scripts/build-web.sh --dev
```
- Starts Vite development server with hot reload
- No build step required
- Fast startup (~350ms)
- Available at http://localhost:8080
- Supports live reload and HMR
- **Source maps enabled** for debugging
### Serve Build Locally
```bash
./scripts/build-web.sh --serve
```
- Builds the application first
- Starts a local HTTP server to serve the built files
- Supports Python HTTP server or npx serve
- Runs on port 8080
## PWA Configuration
### PWA Best Practices Implementation
The TimeSafari web build follows PWA best practices by enabling PWA functionality across all environments:
#### ✅ **Development Mode**
- PWA enabled for development testing
- Service worker registration active
- Manifest generation enabled
- Hot reload compatible
#### ✅ **Test Mode**
- PWA enabled for QA testing
- Service worker registration active
- Manifest generation enabled
- Full PWA feature testing
#### ✅ **Production Mode**
- PWA enabled with full caching strategies
- Service worker registration active
- Manifest generation enabled
- Runtime caching for API calls
- Optimized for production performance
### PWA Features Generated
- `manifest.webmanifest` - PWA manifest with app metadata
- `sw.js` - Service worker for offline functionality
- `workbox-*.js` - Workbox library for caching strategies
- Share target support for image sharing
- Offline-first architecture
### Visual Confirmations of PWA Installation
#### ✅ **Automatic Browser Prompts**
- **Chrome**: Install banner in address bar with install button
- **Safari**: "Add to Home Screen" prompt
- **Edge**: Install button in toolbar
- **Firefox**: Install button in address bar
#### ✅ **Custom Install Prompt**
- **PWAInstallPrompt Component**: Shows when PWA can be installed
- **Install Button**: Prominent blue "Install" button
- **Dismiss Options**: "Later" button and close button
- **Success Notification**: Confirms successful installation
#### ✅ **Post-Installation Indicators**
- **App Icon**: Appears on device home screen/start menu
- **Standalone Window**: Opens without browser UI
- **Native Experience**: Full-screen app-like behavior
- **Offline Capability**: Works without internet connection
#### ✅ **Installation Status Detection**
- **Display Mode Detection**: Checks for standalone/fullscreen modes
- **Service Worker Status**: Monitors service worker registration
- **Install Event Handling**: Listens for successful installation
- **Environment Awareness**: Only shows when PWA is enabled
### Environment Variables Set
- `VITE_PLATFORM=web`
- `VITE_PWA_ENABLED=true`
- `VITE_DISABLE_PWA=false`
- `NODE_ENV` (based on build mode)
- `VITE_GIT_HASH` (from git)
## Environment Management
### Environment File Loading
The script automatically loads environment files based on build mode:
1. `.env.{mode}` (e.g., `.env.test`, `.env.production`)
2. `.env` (fallback)
## Integration with Existing System
### Common Utilities
The script leverages the existing `common.sh` utilities:
- `log_info`, `log_success`, `log_error` - Consistent logging
- `measure_time` - Performance tracking
- `safe_execute` - Error handling
- `setup_build_env` - Environment setup
- `clean_build_artifacts` - Cleanup operations
### Consistent Patterns
Follows the same patterns as other build scripts:
- `build-electron.sh` - Electron builds
- `build-android.sh` - Android builds
- `build-ios.sh` - iOS builds
## Usage Examples
### Basic Builds
```bash
# Development server (starts dev server)
npm run build:web
# Test environment build
npm run build:web:test
# Production build
npm run build:web:prod
```
### Docker Builds
```bash
# Development + Docker
npm run build:web:docker
# Test + Docker
npm run build:web:docker:test
# Production + Docker
npm run build:web:docker:prod
```
### Direct Script Usage
```bash
# Show help
./scripts/build-web.sh --help
# Show environment variables
./scripts/build-web.sh --env
# Verbose logging
./scripts/build-web.sh --test --verbose
```
## Benefits Achieved
### 1. Simplified NPM Scripts
- No more complex command chains
- Single command per script
- Easy to understand and maintain
### 2. Better Error Handling
- Comprehensive error checking
- Clear error messages
- Proper exit codes
### 3. Consistent Logging
- Structured log output
- Performance timing
- Build step tracking
### 4. Environment Management
- Automatic environment file loading
- Platform-specific configurations
- Git hash integration
### 5. Docker Integration
- Seamless Docker builds
- Environment-aware containerization
- Consistent image tagging
## Testing Results
### Build Performance
- **Development Mode**: ~350ms startup time (dev server)
- **Test Mode**: ~11 seconds build time
- **Production Mode**: ~12 seconds build time
### Environment Loading
- Successfully loads `.env.test` for test builds
- Properly sets `NODE_ENV` based on build mode
- Correctly applies Vite mode configurations
### Docker Integration
- Docker builds complete successfully
- Images tagged correctly (`timesafari-web:test`, etc.)
- Build arguments passed properly
## Future Enhancements
### Potential Improvements
1. **Parallel Builds**: Support for parallel asset processing
2. **Build Caching**: Implement build caching for faster rebuilds
3. **Custom Ports**: Allow custom port specification for serve mode
4. **Build Profiles**: Support for custom build profiles
5. **Watch Mode**: Add development watch mode support
### Integration Opportunities
1. **CI/CD Integration**: Easy integration with GitHub Actions
2. **Multi-Platform Builds**: Extend to support other platforms
3. **Build Analytics**: Add build performance analytics
4. **Dependency Checking**: Automatic dependency validation
## Conclusion
The `build-web.sh` script successfully addresses the requirement to prevent scripts from having multiple commands with flags while providing a robust, maintainable, and feature-rich build system for the TimeSafari web application.
The implementation follows established patterns in the codebase, leverages existing utilities, and provides a consistent developer experience across all build modes and platforms.
---
**Status**: ✅ **COMPLETE** - Ready for production use
**Test Coverage**: 100% - All build modes tested and working
**Documentation**: Complete with usage examples and integration guide

View File

@@ -0,0 +1,379 @@
# CEFPython Implementation Guide (Revised)
**Author**: Matthew Raymer
**Date**: 2025-07-12
**Status**: ✨ **PLANNING** - Ready for Implementation
## Overview
This guide outlines the implementation of CEFPython to deliver the TimeSafari Vue.js application as a native desktop experience. It details the integration of Chromium Embedded Framework (CEF) with a Python backend for desktop-specific operations.
## Architecture
### High-Level Diagram
```
TimeSafari CEFPython Architecture
├── Python Backend (CEFPython)
│ ├── CEF Browser Window
│ ├── SQLite Database Access
│ ├── File System Operations
│ └── Native OS Integration
├── Vue.js Frontend (Unchanged)
│ ├── Existing Components
│ ├── Platform Service Integration
│ └── Database Operations
└── Platform Service Bridge
├── CEFPython Platform Service
├── IPC Communication
└── Native API Exposure
```
### Platform Service
A TypeScript class will act as the interface between the Vue frontend and the Python backend:
```typescript
export class CEFPythonPlatformService implements PlatformService {
async dbQuery(sql: string, params?: any[]): Promise<any[]> {
// Call Python backend via IPC
}
async exportData(fileName: string, data: string): Promise<ExportResult> {
// Call file export via IPC
}
async getPlatformInfo(): Promise<PlatformInfo> {
return {
platform: 'cefpython',
capabilities: ['sqlite', 'filesystem', 'native-ui']
};
}
}
```
## Implementation Plan
### Phase 1: Foundation Setup (Week 1)
- [ ] Install CEFPython dependencies
- [ ] Create Python virtual environment
- [ ] Set up development and build tools
- [ ] Create and test minimal CEFPython app
- [ ] Create IPC and platform service skeleton
### Phase 2: SQLite Database (Week 2)
- [ ] Implement Python SQLite wrapper
- [ ] Setup schema initialization
- [ ] Bridge database ops over IPC
- [ ] Test queries and data integrity
### Phase 3: Native OS Integration (Week 3)
- [ ] Implement file import/export
- [ ] Add system tray and notifications
- [ ] Test native menu hooks and permissions
### Phase 4: Build & Packaging (Week 4)
- [ ] Create packaging and build scripts
- [ ] Integrate with existing npm build
- [ ] Automate cross-platform distribution
## Backend Implementation
### Main Entry
```python
# main.py
import cefpython3.cefpython as cef
from platform_service import CEFPythonPlatformService
from ipc_bridge import IPCBridge
class TimeSafariApp:
def __init__(self):
self.platform_service = CEFPythonPlatformService()
self.cef_settings = {
"debug": False,
"log_severity": cef.LOGSEVERITY_ERROR,
"log_file": "cef.log",
"multi_threaded_message_loop": True,
}
def initialize(self):
cef.Initialize(settings=self.cef_settings)
self.browser = cef.CreateBrowserSync(
url=f"file://{os.path.abspath('dist/index.html')}"
)
self.ipc = IPCBridge(self.browser, self.platform_service)
def run(self):
cef.MessageLoop()
cef.Shutdown()
```
### Platform Service (Python)
Handles local database and file system access:
```python
class CEFPythonPlatformService:
def __init__(self):
self.db_path = self._get_db_path()
self._init_schema()
def db_query(self, sql, params=None):
with sqlite3.connect(self.db_path, check_same_thread=False) as conn:
conn.row_factory = sqlite3.Row
return [dict(row) for row in conn.execute(sql, params or [])]
def db_exec(self, sql, params=None):
with sqlite3.connect(self.db_path, check_same_thread=False) as conn:
cur = conn.execute(sql, params or [])
conn.commit()
return {"changes": cur.rowcount, "lastId": cur.lastrowid}
def export_data(self, file_name, data):
try:
path = os.path.join(self._get_downloads(), file_name)
with open(path, 'w') as f:
f.write(data)
return {"success": True, "path": path}
except Exception as e:
return {"success": False, "error": str(e)}
```
### IPC Bridge
Handles communication from JavaScript:
```python
class IPCBridge:
def __init__(self, browser, platform_service):
self.browser = browser
self.platform_service = platform_service
bindings = cef.JavascriptBindings()
bindings.SetFunction("callPython", self.call)
self.browser.SetJavascriptBindings(bindings)
def call(self, name, args):
handlers = {
"dbQuery": self.platform_service.db_query,
"dbExec": self.platform_service.db_exec,
"exportData": self.platform_service.export_data
}
try:
return {"success": True, "data": handlers[name](*args)}
except Exception as e:
return {"success": False, "error": str(e)}
```
## Build & Packaging
Shell script with build modes:
```bash
npm run build:web:dev
./scripts/build-cefpython.sh --dev
```
Includes PyInstaller packaging:
```bash
pyinstaller --onefile --windowed --name TimeSafari main.py
```
## Package.json Integration
### CEFPython Build Scripts
```json
{
"scripts": {
// CEFPython builds
"build:cefpython": "./scripts/build-cefpython.sh",
"build:cefpython:dev": "./scripts/build-cefpython.sh --dev",
"build:cefpython:test": "./scripts/build-cefpython.sh --test",
"build:cefpython:prod": "./scripts/build-cefpython.sh --prod",
"build:cefpython:package": "./scripts/build-cefpython.sh --prod --package",
// Legacy aliases
"build:desktop:cef": "npm run build:cefpython",
"build:desktop:cef:dev": "npm run build:cefpython:dev",
"build:desktop:cef:prod": "npm run build:cefpython:prod"
}
}
```
## Platform Service Factory Integration
### Update PlatformServiceFactory
```typescript
// src/services/PlatformServiceFactory.ts
export class PlatformServiceFactory {
private static instance: PlatformService | null = null;
public static getInstance(): PlatformService {
if (!PlatformServiceFactory.instance) {
const platform = process.env.VITE_PLATFORM || "web";
switch (platform) {
case "cefpython":
PlatformServiceFactory.instance = new CEFPythonPlatformService();
break;
case "electron":
PlatformServiceFactory.instance = new ElectronPlatformService();
break;
case "capacitor":
PlatformServiceFactory.instance = new CapacitorPlatformService();
break;
default:
PlatformServiceFactory.instance = new WebPlatformService();
}
}
return PlatformServiceFactory.instance;
}
}
```
## Development Workflow
```bash
cd cefpython
pip install -r requirements.txt
npm run build:cefpython:dev
```
## Platform Considerations
### Windows
- VC++ Redistributable
- Registry for settings
### macOS
- macOS 10.14+
- Handle App Sandbox
### Linux
- GTK dependencies
- Provide `.desktop` launcher
## Security Considerations
- CEF sandboxing
- File and IPC validation
- Data encryption & key management
- Code signing & integrity checks
## Performance Optimization
### 1. Memory Management
- Implement proper cleanup
- Monitor memory usage
- Optimize database queries
- Handle large datasets
### 2. Startup Time
- Optimize application startup
- Implement lazy loading
- Cache frequently used data
- Minimize initialization overhead
### 3. Resource Usage
- Monitor CPU usage
- Optimize rendering
- Handle background tasks
- Implement resource limits
## Testing
- Unit tests for each service
- Integration for IPC and file access
- End-to-end for user workflows
## Issues & Suggestions for Improvement
### 1. IPC Registration Missing in Initial Version
You must explicitly bind Python functions to JS:
```python
bindings.SetFunction("callPython", self.call)
```
### 2. Incorrect `IPCBridge` Constructor in Early Draft
Original:
```python
def __init__(self, browser):
```
Fixed:
```python
def __init__(self, browser, platform_service):
```
### 3. SQLite Threading Caveat
Add `check_same_thread=False` or use a threading queue to avoid crashes from multi-threaded access.
### 4. No Vue IPC Access Description
Specify the frontend JS API for calling Python:
```javascript
window.callPython('dbQuery', ['SELECT * FROM accounts'])
```
### 5. Missing Cleanup in Unit Tests
Add teardown for exported files to avoid clutter and permissions issues.
### 6. Logging
Add `logging` or `structlog` to the Python service and bridge for auditability.
## Troubleshooting
### Common Issues
#### 1. CEF Initialization Failures
```bash
# Check CEF installation
python -c "import cefpython3; print('CEF installed')"
# Verify dependencies
pip list | grep cefpython3
```
#### 2. Database Access Issues
```bash
# Check database permissions
ls -la ~/.local/share/timesafari/
# Verify SQLite installation
python -c "import sqlite3; print('SQLite available')"
```
#### 3. Build Failures
```bash
# Clean and rebuild
rm -rf cefpython/dist/
rm -rf cefpython/build/
npm run build:cefpython:dev
```
### Debug Mode
```python
# Enable debug logging
cef_settings = {
"debug": True,
"log_severity": cef.LOGSEVERITY_VERBOSE,
"log_file": "cef_debug.log",
}
```
## Conclusion
This guide offers a clear and technically complete roadmap for integrating CEFPython with TimeSafari. By implementing the suggestions above, the solution will be production-ready with complete platform service integration, desktop capability, and a stable build process.
**Effort**: 4 weeks
**Priority**: Medium
**Dependencies**: Python 3.8+, CEFPython
**Stakeholders**: Desktop development team, users

677
docs/chrome_devtools.md Normal file
View File

@@ -0,0 +1,677 @@
# Chrome DevTools MCP
A Model Context Protocol (MCP) server that provides Chrome DevTools Protocol integration through MCP. This allows you to debug web applications by connecting to Chrome's developer tools.
**Available as a Claude Desktop Extension (.dxt)** for easy one-click installation!
## What This Does
This MCP server acts as a bridge between Claude and Chrome's debugging capabilities. Once installed in Claude Desktop, you can:
- Connect Claude to any web application running in Chrome
- Debug network requests, console errors, and performance issues
- Inspect JavaScript objects and execute code in the browser context
- Monitor your application in real-time through natural conversation with Claude
**Note**: This is an MCP server that runs within Claude Desktop - you don't need to run any separate servers or processes.
## Features
- **Network Monitoring**: Capture and analyse HTTP requests/responses with filtering options
- **Console Integration**: Read browser console logs, analyse errors, and execute JavaScript
- **Performance Metrics**: Timing data, resource loading, and memory utilisation
- **Page Inspection**: DOM information, page metrics, and multi-frame support
- **Storage Access**: Read cookies, localStorage, and sessionStorage
- **Real-time Monitoring**: Live console output tracking
- **Object Inspection**: Inspect JavaScript objects and variables
## Installation
### Option 1: Claude Desktop Extension (Easiest)
**Download the pre-built extension:**
1. Download the latest `.dxt` file from [Releases](https://github.com/benjaminr/chrome-devtools-mcp/releases)
2. Open Claude Desktop
3. Go to Extensions and install the downloaded `.dxt` file
4. Configure Chrome path if needed in extension settings
The extension includes all dependencies and is ready to use immediately!
### Option 2: MCP CLI (Advanced)
**Quick Install (most common):**
```bash
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
mcp install server.py -n "Chrome DevTools MCP" --with-editable .
```
**All Installation Options:**
```bash
# Clone the repository
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
# The --with-editable flag uses pyproject.toml to install dependencies
# Basic installation with local dependencies
mcp install server.py --with-editable .
# Install with custom name
mcp install server.py -n "Chrome DevTools MCP" --with-editable .
# Install with environment variables
mcp install server.py -n "Chrome DevTools MCP" --with-editable . -v CHROME_DEBUG_PORT=9222
# Install with additional packages if needed
mcp install server.py -n "Chrome DevTools MCP" --with-editable . --with websockets --with aiohttp
# Install with environment file (copy .env.example to .env first)
cp .env.example .env
# Edit .env with your settings
mcp install server.py -n "Chrome DevTools MCP" --with-editable . -f .env
```
### Option 3: Claude Code Integration
**For Claude Code CLI users:**
1. **Clone this repository**
```bash
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
```
2. **Install dependencies**
```bash
uv sync # or pip install -r requirements.txt
```
3. **Add MCP server using Claude CLI**
**Quick setup (recommended):**
```bash
# Add the server with environment variable
claude mcp add chrome-devtools python server.py -e CHROME_DEBUG_PORT=9222
```
**With custom scope:**
```bash
# Add to user scope (available across all projects)
claude mcp add chrome-devtools python server.py -s user -e CHROME_DEBUG_PORT=9222
# Add to project scope (only for this project)
claude mcp add chrome-devtools python server.py -s project -e CHROME_DEBUG_PORT=9222
```
4. **Verify installation**
```bash
# List configured MCP servers
claude mcp list
# Get details about the server
claude mcp get chrome-devtools
```
### Option 4: Manual Claude Desktop Setup
1. **Clone this repository**
```bash
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
```
2. **Install dependencies**
**With uv (recommended):**
```bash
uv sync
```
**With pip:**
```bash
pip install -r requirements.txt
```
3. **Add to Claude Desktop configuration**
Edit your Claude Desktop config file:
- **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json`
- **Windows**: `%APPDATA%/Claude/claude_desktop_config.json`
```json
{
"mcpServers": {
"chrome-devtools": {
"command": "python",
"args": ["/absolute/path/to/chrome-devtools-mcp/server.py"],
"env": {
"CHROME_DEBUG_PORT": "9222"
}
}
}
}
```
4. **Restart Claude Desktop**
### Verify Installation
After installation (either method), verify the server is available:
1. Open Claude Desktop
2. Look for MCP tools in the conversation
3. Try a simple command: `get_connection_status()`
### Alternative MCP Clients
For other MCP clients, run the server directly:
```bash
python server.py
```
## Quick Start
Once installed in Claude Desktop, you can start debugging any web application:
### Debug Your Web Application
**One-step setup (recommended):**
```
start_chrome_and_connect("localhost:3000")
```
*Replace `localhost:3000` with your application's URL*
**If Chrome isn't found automatically:**
```
start_chrome_and_connect("localhost:3000", chrome_path="/path/to/chrome")
```
*Use the `chrome_path` parameter to specify a custom Chrome location*
This command will:
- Start Chrome with debugging enabled
- Navigate to your application
- Connect the MCP server to Chrome
**Manual setup (if you prefer step-by-step):**
```
start_chrome()
navigate_to_url("localhost:3000")
connect_to_browser()
```
### Start Debugging
Once connected, use these commands:
- `get_network_requests()` - View HTTP traffic
- `get_console_error_summary()` - Analyse JavaScript errors
- `inspect_console_object("window")` - Inspect any JavaScript object
## Available MCP Tools
### Chrome Management
- `start_chrome(port?, url?, headless?, chrome_path?, auto_connect?)` - Start Chrome with remote debugging and optional auto-connection
- `start_chrome_and_connect(url, port?, headless?, chrome_path?)` - Start Chrome, connect, and navigate in one step
- `connect_to_browser(port?)` - Connect to existing Chrome instance
- `navigate_to_url(url)` - Navigate to a specific URL
- `disconnect_from_browser()` - Disconnect from browser
- `get_connection_status()` - Check connection status
### Network Monitoring
- `get_network_requests(filter_domain?, filter_status?, limit?)` - Get network requests with filtering
- `get_network_response(request_id)` - Get detailed response data including body
### Console Tools
- `get_console_logs(level?, limit?)` - Get browser console logs
- `get_console_error_summary()` - Get organized summary of errors and warnings
- `execute_javascript(code)` - Execute JavaScript in browser context
- `clear_console()` - Clear the browser console
- `inspect_console_object(expression)` - Deep inspect any JavaScript object
- `monitor_console_live(duration_seconds)` - Monitor console output in real-time
### Page Analysis
- `get_page_info()` - Get comprehensive page metrics and performance data
- `evaluate_in_all_frames(code)` - Execute JavaScript in all frames/iframes
- `get_performance_metrics()` - Get detailed performance metrics and resource timing
### Storage & Data
- `get_storage_usage_and_quota(origin)` - Get storage usage and quota information
- `clear_storage_for_origin(origin, storage_types?)` - Clear storage by type and origin
- `get_all_cookies()` - Get all browser cookies
- `clear_all_cookies()` - Clear all browser cookies
- `set_cookie(name, value, domain, path?, expires?, http_only?, secure?, same_site?)` - Set a cookie
- `get_cookies(domain?)` - Get browser cookies with optional domain filtering
- `get_storage_key_for_frame(frame_id)` - Get storage key for a specific frame
- `track_cache_storage(origin, enable?)` - Enable/disable cache storage tracking
- `track_indexeddb(origin, enable?)` - Enable/disable IndexedDB tracking
- `override_storage_quota(origin, quota_size_mb?)` - Override storage quota
## Use Cases
### Debugging API Calls in Your Web Application
When your web application makes API calls that fail or return unexpected data:
**Easy setup:** Use the one-step command to start Chrome and navigate to your app:
**Example workflow:**
```
You: "I need to debug my React app at localhost:3000"
Claude: I'll start Chrome with debugging enabled and navigate to your app.
start_chrome_and_connect("localhost:3000")
Perfect! Chrome is now running with debugging enabled and connected to your app. Let me check for any failed network requests:
get_network_requests(filter_status=500)
I can see there are 3 failed requests to your API. Let me get the details of the first one:
get_network_response("request-123")
```
**Manual setup (if you prefer):**
1. **Start Chrome**: Use `start_chrome()`
2. **Navigate to your app**: Use `navigate_to_url("localhost:3000")`
3. **Connect**: Use `connect_to_browser()`
4. **Monitor network traffic**: Use `get_network_requests()` to see all API calls
### Checking JavaScript Console Errors
When your web application has JavaScript errors or unexpected behaviour:
1. **Navigate to your application** in the connected Chrome instance
2. **Check for console errors**: Use `get_console_error_summary()` to see all errors
3. **Monitor live errors**: Use `monitor_console_live(10)` to watch for new errors as you interact
4. **Inspect variables**: Use `inspect_console_object("myVariable")` to examine application state
**Example workflow:**
```
You: "My React component isn't updating properly"
Claude: Let me check the JavaScript console for any errors.
get_console_error_summary()
I can see there are 2 JavaScript errors. Let me also monitor the console while you interact with the component:
monitor_console_live(15)
Now try clicking the component that isn't working. I'll watch for any new errors or warnings.
```
### Performance Debugging
When your web application loads slowly or uses too much memory:
1. **Load your application** in the connected browser
2. **Check page metrics**: Use `get_page_info()` to see load times and resource counts
3. **Analyse performance**: Use `get_performance_metrics()` to see detailed timing data
4. **Monitor memory usage**: Check the memory information in the performance metrics
**Example workflow:**
```
You: "My application takes too long to load"
Claude: Let me analyse the performance of your application.
get_page_info()
I can see your page has 47 scripts and took 3.2 seconds to load. Let me get more detailed performance data:
get_performance_metrics()
The main bottleneck is the initial JavaScript bundle which is 2.1MB. The DOM processing also takes 800ms.
```
### Debugging Authentication Issues
When login or session management isn't working:
1. **Navigate to your login page**
2. **Check cookies**: Use `get_cookies()` to see authentication cookies
3. **Monitor network during login**: Use `monitor_console_live()` and `get_network_requests()` during the login process
4. **Examine stored data**: Use JavaScript execution to check localStorage/sessionStorage
**Example workflow:**
```
You: "Users can't stay logged in"
Claude: Let me check the authentication setup.
get_cookies()
I can see the auth cookie is present. Let me check what happens during login by monitoring the network:
get_network_requests(filter_domain="your-api.com")
I notice the login request returns a 200 but no Set-Cookie header. Let me also check localStorage:
execute_javascript("Object.keys(localStorage)")
```
### DOM Element Inspection
- `get_document(depth?, pierce?)` - Retrieve DOM document structure
- `query_selector(node_id, selector)` - Find single element by CSS selector
- `query_selector_all(node_id, selector)` - Find multiple elements by CSS selector
- `get_element_attributes(node_id)` - Get all attributes of an element
- `get_element_outer_html(node_id)` - Get outer HTML of an element
- `get_element_box_model(node_id)` - Get layout information
- `describe_element(node_id, depth?)` - Get detailed element description
- `get_element_at_position(x, y)` - Get element at screen position
- `search_elements(query)` - Search DOM elements by text/attributes
- `focus_element(node_id)` - Focus a DOM element
### CSS Style Analysis
- `get_computed_styles(node_id)` - Get computed CSS styles
- `get_inline_styles(node_id)` - Get inline styles
- `get_matched_styles(node_id)` - Get all CSS rules matching an element
- `get_stylesheet_text(stylesheet_id)` - Get stylesheet content
- `get_background_colors(node_id)` - Get background colors and fonts
- `get_platform_fonts(node_id)` - Get platform font information
- `get_media_queries()` - Get all media queries
- `collect_css_class_names(stylesheet_id)` - Collect CSS class names
- `start_css_coverage_tracking()` - Start CSS coverage tracking
- `stop_css_coverage_tracking()` - Stop and get CSS coverage results
## Common Commands
| Task | Command |
|------|---------|
| Start Chrome and connect to app | `start_chrome_and_connect("localhost:3000")` |
| Start Chrome (manual setup) | `start_chrome()` |
| Navigate to page | `navigate_to_url("localhost:3000")` |
| Connect to browser | `connect_to_browser()` |
| See all network requests | `get_network_requests()` |
| Find failed API calls | `get_network_requests(filter_status=404)` |
| Check for JavaScript errors | `get_console_error_summary()` |
| Watch console in real-time | `monitor_console_live(10)` |
| Check page load performance | `get_page_info()` |
| Examine a variable | `inspect_console_object("window.myApp")` |
| View cookies | `get_cookies()` |
| Run JavaScript | `execute_javascript("document.title")` |
## Configuration
### Environment Variables
- `CHROME_DEBUG_PORT` - Chrome remote debugging port (default: 9222)
### MCP Compatibility
- **MCP Protocol Version**: 2024-11-05
- **Minimum Python Version**: 3.10+
- **Supported MCP Clients**: Claude Desktop, any MCP-compatible client
- **Package Manager**: uv (recommended) or pip
## Usage Workflow
### Prerequisites (Your Development Environment)
- Have your web application running (e.g., `npm run dev`, `python -m http.server`, etc.)
- Note the URL where your application is accessible
### Debugging Session
1. **Connect to your application** via Claude Desktop:
```
start_chrome_and_connect("localhost:3000")
```
*Replace with your application's URL*
2. **Debug your application** using the MCP tools:
- Monitor network requests
- Check console errors
- Inspect JavaScript objects
- Analyse performance
3. **Make changes to your code** in your editor
4. **Refresh or interact** with your application
5. **Continue debugging** with real-time data
### Manual Connection (Alternative)
If you prefer step-by-step control:
1. `start_chrome()` - Launch Chrome with debugging
2. `navigate_to_url("your-app-url")` - Navigate to your application
3. `connect_to_browser()` - Connect the MCP server
4. Use debugging tools as needed
## Security Notes
- Only use with development environments
- Never connect to production Chrome instances
- The server is designed for localhost debugging only
- No data is stored permanently - all data is session-based
## Troubleshooting
### Server Shows as "Disabled" in Claude Desktop
If the server appears in Claude but shows as "disabled", try these steps:
1. **Check Claude Desktop logs**:
- **macOS**: `~/Library/Logs/Claude/mcp*.log`
- **Windows**: `%APPDATA%/Claude/logs/mcp*.log`
2. **Common fixes**:
```bash
# Reinstall with verbose output
mcp remove "Chrome DevTools MCP"
mcp install server.py -n "Chrome DevTools MCP" --with-editable . -v CHROME_DEBUG_PORT=9222
# Check installation status
mcp list
# Test the server manually
python3 server.py
```
3. **Check dependencies**:
```bash
# Ensure all dependencies are available
pip install mcp websockets aiohttp
# Test imports
python3 -c "from server import mcp; print('OK')"
```
4. **Restart Claude Desktop** completely (quit and reopen)
### Installation Issues
- **MCP CLI not found**: Install MCP CLI with `pip install mcp` or `npm install -g @modelcontextprotocol/cli`
- **Server not appearing in Claude**:
- For MCP CLI: Run `mcp list` to verify the server is installed
- For manual setup: Check Claude Desktop configuration file path and JSON syntax
- **Import errors**:
- For MCP CLI: Use `--with-editable .` to install local dependencies
- For manual setup: Run `pip install -r requirements.txt`
- **Permission errors**: Use absolute paths in configuration
- **Environment variables not working**: Verify `.env` file format or `-v` flag syntax
- **Module not found**: Ensure you're using `--with-editable .` flag for local package installation
### Debugging Steps
**Step 1: Check MCP CLI Status**
```bash
# List all installed servers
mcp list
# Check specific server status
mcp status "Chrome DevTools MCP"
```
**Step 2: Test Server Manually**
```bash
# Test if server starts without errors
python3 server.py
# Test imports
python3 -c "from server import mcp; print(f'Server: {mcp.name}')"
```
**Step 3: Check Configuration**
**For Claude Desktop:**
```bash
# View current configuration (macOS)
cat "~/Library/Application Support/Claude/claude_desktop_config.json"
# View current configuration (Windows)
type "%APPDATA%/Claude/claude_desktop_config.json"
```
**For Claude Code:**
```bash
# List configured MCP servers
claude mcp list
# Get details about a specific server
claude mcp get chrome-devtools
# Check if server is working
claude mcp serve --help
```
**Step 4: Reinstall if Needed**
**For MCP CLI:**
```bash
# Clean reinstall
mcp remove "Chrome DevTools MCP"
mcp install server.py -n "Chrome DevTools MCP" --with-editable .
# Restart Claude Desktop completely
```
**For Claude Code:**
```bash
# Remove and re-add the server
claude mcp remove chrome-devtools
claude mcp add chrome-devtools python server.py -e CHROME_DEBUG_PORT=9222
# Or update with different scope
claude mcp add chrome-devtools python server.py -s user -e CHROME_DEBUG_PORT=9222
```
### Common Error Messages
| Error | Solution |
|-------|----------|
| "Module not found" | Use `--with-editable .` flag |
| "No server object found" | Server should export `mcp` object (already fixed) |
| "Import error" | Check `pip install mcp websockets aiohttp` |
| "Permission denied" | Use absolute paths in config |
| "Server disabled" | Check Claude Desktop logs, restart Claude |
### Manual Configuration Fallback
**For Claude Desktop:**
If MCP CLI isn't working, add this to Claude Desktop config manually:
```json
{
"mcpServers": {
"chrome-devtools": {
"command": "python3",
"args": ["/absolute/path/to/chrome-devtools-mcp/server.py"],
"env": {
"CHROME_DEBUG_PORT": "9222"
}
}
}
}
```
**For Claude Code:**
If the `claude mcp add` command isn't working, you can use the JSON format:
```bash
# Add server using JSON configuration
claude mcp add-json chrome-devtools '{
"command": "python3",
"args": ["'$(pwd)'/server.py"],
"env": {
"CHROME_DEBUG_PORT": "9222"
}
}'
# Or import from Claude Desktop if you have it configured there
claude mcp add-from-claude-desktop
```
### Connection Issues
- **Chrome won't start**: The MCP server will start Chrome automatically when you use `start_chrome()`
- **Can't connect**: Try `get_connection_status()` to check the connection
- **Tools not working**: Ensure you've called `connect_to_browser()` or used `start_chrome_and_connect()`
### Common Misconceptions
- **This is not a web server**: The MCP server runs inside Claude Desktop, not as a separate web service
- **No separate installation needed**: Once configured in Claude Desktop, the server starts automatically
- **Your app runs separately**: This tool connects to your existing web application, it doesn't run it
## Development & Testing
*This section is for developers who want to test or modify the MCP server itself.*
### Development Setup
**With uv (recommended):**
```bash
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
uv sync
```
**With pip:**
```bash
git clone https://github.com/benjaminr/chrome-devtools-mcp.git
cd chrome-devtools-mcp
pip install -e ".[dev]"
```
### Code Quality Tools
```bash
# Format code
uv run ruff format .
# Lint code
uv run ruff check .
# Type checking
uv run mypy src/
```
### Building the Extension
**Install DXT packaging tools:**
```bash
npm install -g @anthropic-ai/dxt
```
**Build the extension:**
```bash
# Quick build
make package
# Or manually
npx @anthropic-ai/dxt pack
```
**Using Makefile for development:**
```bash
make help # Show all commands
make install # Install dependencies
make dev # Setup development environment + pre-commit
make check # Run all checks (lint + type + test)
make pre-commit # Run pre-commit hooks manually
make package # Build .dxt extension
make release # Full release build
```
### Pre-commit Hooks
This project uses pre-commit hooks to ensure code quality:
- **ruff**: Linting and formatting
- **mypy**: Type checking
- **pytest**: Test validation
- **MCP validation**: Server registration check
Pre-commit hooks run automatically on `git commit` and can be run manually with `make pre-commit`.
## License
MIT License

View File

@@ -0,0 +1,140 @@
# TimeSafari Commit Message Template with Time Tracking
## Migration Commit Template
```
[Component]: Complete Enhanced Triple Migration Pattern (X minutes)
Database Migration: Replace databaseUtil with PlatformServiceMixin
SQL Abstraction: Use $contacts(), $settings(), $platformService methods
Notification Migration: Add X constants, migrate X $notify calls to helpers
Template Optimization: Extract X computed properties, reduce complexity
Time: X minutes | Complexity: [Simple/Medium/Complex] | Issues: [None/List]
Testing: [Manual/Automated/Required] | Validation: [Script passed/Manual check]
```
## Real Examples from Recent Work
### PhotoDialog + OfferDialog (58 minutes each)
```
Complete Enhanced Triple Migration Pattern for PhotoDialog and OfferDialog (116 minutes)
Database Migration: Replace databaseUtil with PlatformServiceMixin
SQL Abstraction: Use $accountSettings() for settings retrieval
Notification Migration: Add 15 constants, migrate 15 $notify calls to helpers
Template Optimization: Extract 11 computed properties, reduce template complexity
Time: 116 minutes | Complexity: Medium | Issues: None
Testing: Manual | Validation: Script passed
```
### ProjectsView (17 minutes)
```
Complete ProjectsView Triple Migration Pattern with literal extraction (17 minutes)
Database Migration: Replace databaseUtil with PlatformServiceMixin
SQL Abstraction: Use $contacts(), $projects() methods
Notification Migration: Add 1 constant, migrate 1 $notify call
Template Optimization: Extract 3 computed properties
Time: 17 minutes | Complexity: Simple | Issues: None
Testing: Automated | Validation: Script passed
```
## Batch Migration Template
```
Complete notification migration across X components (Y minutes)
Components: [List of components]
- Add X centralized notification constants
- Migrate X $notify calls to helper methods
- Standardize timeout usage with TIMEOUTS constants
Time: Y minutes | Avg per component: Z minutes | Complexity: Batch
Testing: Automated | Validation: Script passed
```
## Time Tracking Workflow
### 1. Start Migration
```bash
./scripts/time-migration.sh ComponentName.vue start
```
### 2. Complete Migration
```bash
./scripts/time-migration.sh ComponentName.vue end
```
### 3. Daily Summary
```bash
./scripts/daily-migration-summary.sh
```
### 4. Commit with Time Data
```bash
git commit -m "Complete ComponentName migration (X minutes)
Database Migration: Replace databaseUtil with PlatformServiceMixin
Notification Migration: Add X constants, migrate X $notify calls
Template Optimization: Extract X computed properties
Time: X minutes | Complexity: [Level] | Issues: [None/List]
Testing: [Status] | Validation: [Status]"
```
## Time Complexity Guidelines
### Simple Components (15-20 minutes)
- Dialog components with minimal database operations
- Utility components with few notifications
- Example: UserNameDialog, TopMessage
### Medium Components (30-45 minutes)
- Standard view components with moderate database usage
- Multiple notification patterns
- Example: ProjectsView, ContactsView
### Complex Components (45-60 minutes)
- Large view components with extensive database operations
- Many notification patterns and complex templates
- Example: PhotoDialog, OfferDialog, ConfirmGiftView
## Performance Tracking
### Daily Targets
- **Simple Components**: 20+ per day
- **Medium Components**: 8-12 per day
- **Complex Components**: 4-8 per day
### Weekly Targets
- **Week 1**: 25 components (mix of simple/medium)
- **Week 2**: 30 components (focus on complex)
- **Week 3**: 37 components (remaining)
### Quality Gates
- [ ] Start time logged
- [ ] End time logged
- [ ] Validation script passed
- [ ] Linting passed
- [ ] Commit includes time data
- [ ] Daily summary updated
## Efficiency Tips
### Batch Processing
- Group similar components
- Reuse notification constants
- Copy/paste helper patterns
### Templates and Automation
- Use migration checklist
- Standardize computed property patterns
- Validate with scripts
### Time Savers
- Keep validation script running
- Use IDE snippets for common patterns
- Track blockers immediately

146
docs/database-clearing.md Normal file
View File

@@ -0,0 +1,146 @@
# Database Clearing for Development
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: **ACTIVE** - Production Ready
## Overview
TimeSafari provides a simple script-based approach to clear the database for development purposes. This avoids the complexity of programmatic database clearing and provides reliable, platform-specific solutions.
## Quick Start
```bash
# Run the interactive database clearing script
./scripts/clear-database.sh
# Then restart your development server
npm run build:electron:dev # For Electron
npm run build:web:dev # For Web
```
## Platform-Specific Approaches
### Electron (Desktop App)
The script automatically detects your platform and clears the SQLite database files:
- **Linux**: `~/.config/TimeSafari/`
- **macOS**: `~/Library/Application Support/TimeSafari/`
- **Windows**: `%APPDATA%\TimeSafari`
### Web Browser
For web browsers, the script provides two approaches:
#### 1. Custom Data Directory (Recommended)
Create an isolated browser profile for development:
```bash
# Create isolated profile
mkdir ~/timesafari-dev-data
# Start browser with custom profile
google-chrome --user-data-dir=~/timesafari-dev-data
# Clear when needed
rm -rf ~/timesafari-dev-data
```
#### 2. Manual Browser Clearing
Use browser DevTools to clear IndexedDB:
1. Open Developer Tools (F12)
2. Go to Application/Storage tab
3. Find 'IndexedDB' section
4. Delete 'TimeSafari' database
5. Refresh the page
## Why Script-Based Approach?
### **Simplicity**
- No complex programmatic database clearing
- No browser storage complications
- No race conditions or permission issues
### **Reliability**
- Direct file system access for Electron
- Isolated browser profiles for web
- Clear, predictable behavior
### **Safety**
- Interactive script guides users
- Platform-specific instructions
- Only clears TimeSafari data
## Manual Commands
If you prefer manual commands:
### Electron
```bash
# Linux
rm -rf ~/.config/TimeSafari/*
# macOS
rm -rf ~/Library/Application\ Support/TimeSafari/*
# Windows
rmdir /s /q %APPDATA%\TimeSafari
```
### Web Browser
```bash
# Create and use isolated profile
mkdir ~/timesafari-dev-data
google-chrome --user-data-dir=~/timesafari-dev-data
# Clear when needed
rm -rf ~/timesafari-dev-data
```
## Best Practices
1. **Stop the development server** before clearing
2. **Use isolated browser profiles** for web development
3. **Restart the development server** after clearing
4. **Backup important data** before clearing
5. **Use the script** for consistent behavior
## Troubleshooting
### Script Not Found
```bash
# Make sure script is executable
chmod +x scripts/clear-database.sh
# Run from project root
./scripts/clear-database.sh
```
### Permission Errors
```bash
# Check file permissions
ls -la ~/.config/TimeSafari/
# Use sudo if needed (rare)
sudo rm -rf ~/.config/TimeSafari/*
```
### Browser Profile Issues
```bash
# Ensure browser is completely closed
pkill -f chrome
pkill -f firefox
# Then clear profile
rm -rf ~/timesafari-dev-data
```
---
**Last Updated**: 2025-07-11
**Version**: 1.0.3-beta
**Status**: Production Ready

View File

@@ -0,0 +1,174 @@
# Electron Auto-Updates Configuration
**Author**: Matthew Raymer
**Date**: 2025-07-12
**Status**: **DISABLED** - Manual Updates Only
## Overview
TimeSafari's Electron application currently has auto-updates disabled due to hosting on Gitea instead of GitHub. This document explains the current configuration and provides guidance for future update mechanisms.
## Current Status
### Auto-Updates Disabled
Auto-updates are currently disabled for the following reasons:
1. **Repository Hosting**: The project is hosted on Gitea (`https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa`) rather than GitHub
2. **Provider Limitations**: `electron-updater` primarily supports GitHub, S3, and other major cloud providers
3. **404 Errors**: Attempting to use GitHub auto-updates with a Gitea repository causes 404 errors
### Configuration Changes Made
1. **Repository URL Updated**: Changed from `https://github.com/trentlarson/crowd-master` to the correct Gitea URL
2. **Publish Configuration Removed**: Removed GitHub provider from `electron-builder.config.json`
3. **Auto-Updater Disabled**: Commented out auto-updater code in `electron/src/index.ts`
## Error Resolution
The original error:
```
HttpError: 404
"method: GET url: https://github.com/trentlarson/crowd-master/releases.atom"
```
This occurred because:
- The app was trying to check for updates on GitHub
- The repository doesn't exist on GitHub
- The auto-updater was configured for GitHub releases
## Future Update Options
### Option 1: Manual Distribution
- Build and distribute packages manually
- Users download and install new versions manually
- No automatic update checking
### Option 2: Custom Update Server
- Implement a custom update server compatible with `electron-updater`
- Host update files on a web server
- Configure custom update endpoints
### Option 3: GitHub Migration
- Move repository to GitHub
- Set up GitHub releases
- Re-enable auto-updates
### Option 4: Alternative Update Providers
- Use S3 or other supported providers
- Implement custom update mechanism
- Use third-party update services
## Current Build Process
### Development Builds
```bash
npm run build:electron:dev
```
### Production Builds
```bash
npm run build:electron:prod
```
### Package Distribution
```bash
# Windows
npm run build:electron:windows:prod
# macOS
npm run build:electron:mac:prod
# Linux
npm run build:electron:linux:prod
```
## Manual Update Process
1. **Build New Version**: Use appropriate build script
2. **Test Package**: Verify the built package works correctly
3. **Distribute**: Share the package with users
4. **User Installation**: Users manually download and install
## Security Considerations
### Disabled Auto-Updates
- No automatic security updates
- Users must manually update for security patches
- Consider implementing update notifications
### Package Verification
- Verify package integrity before distribution
- Use code signing for packages
- Implement checksum verification
## Monitoring and Maintenance
### Version Tracking
- Track application versions manually
- Document changes between versions
- Maintain changelog for users
### User Communication
- Notify users of available updates
- Provide clear update instructions
- Document breaking changes
## Recommendations
### Short Term
1. Continue with manual distribution
2. Implement update notifications in-app
3. Provide clear update instructions
### Long Term
1. Evaluate hosting platform options
2. Consider implementing custom update server
3. Plan for automated update mechanism
## Configuration Files
### electron-builder.config.json
```json
{
"appId": "app.timesafari.desktop",
"productName": "TimeSafari",
// publish configuration removed
}
```
### electron/src/index.ts
```typescript
// Auto-updater disabled
// import { autoUpdater } from 'electron-updater';
// Auto-updates disabled - not supported on Gitea hosting
// if (!electronIsDev && !process.env.APPIMAGE) {
// try {
// autoUpdater.checkForUpdatesAndNotify();
// } catch (error) {
// console.log('Update check failed (suppressed):', error);
// }
// }
```
## Troubleshooting
### Common Issues
1. **404 Errors**: Ensure repository URL is correct
2. **Build Failures**: Check build configuration
3. **Package Issues**: Verify package contents
### Debug Mode
```bash
# Enable debug logging
DEBUG=* npm run build:electron:dev
```
---
**Status**: Auto-updates disabled
**Last Updated**: 2025-07-12
**Version**: 1.0
**Maintainer**: Matthew Raymer

View File

@@ -0,0 +1,594 @@
# Electron Build Patterns
**Author**: Matthew Raymer
**Date**: 2025-01-27
**Status**: 🎯 **ACTIVE** - Current Implementation
## Overview
TimeSafari's Electron build system provides comprehensive packaging and
distribution capabilities across Windows, macOS, and Linux platforms. The
system supports multiple build modes, environment configurations, and
package formats for different deployment scenarios.
## Build Architecture
### Multi-Stage Build Process
```
1. Web Build (Vite) → 2. Capacitor Sync → 3. TypeScript Compile → 4. Package
```
**Stage 1: Web Build**
- Vite builds web assets with Electron-specific configuration
- Environment variables loaded based on build mode
- Assets optimized for desktop application
**Stage 2: Capacitor Sync**
- Copies web assets to Electron app directory
- Syncs Capacitor configuration and plugins
- Prepares native module bindings
**Stage 3: TypeScript Compile**
- Compiles Electron main process TypeScript
- Rebuilds native modules for target platform
- Generates production-ready JavaScript
**Stage 4: Package Creation**
- Creates platform-specific installers
- Generates distribution packages
- Signs applications (when configured)
## Build Modes
### Development Mode (--mode development)
**Purpose**: Local development and testing
**Configuration**: Development environment variables
**Output**: Unpacked application for testing
```bash
# Development build (runs app)
npm run build:electron:dev
# Development build with explicit mode
npm run build:electron -- --mode development
```
**Features**:
- Hot reload enabled
- Debug tools available
- Development logging
- Unoptimized assets
### Testing Mode (--mode test)
**Purpose**: Staging and testing environments
**Configuration**: Test environment variables
**Output**: Packaged application for testing
```bash
# Test build
npm run build:electron -- --mode test
# Test build with specific platform
npm run build:electron:windows -- --mode test
npm run build:electron:mac -- --mode test
npm run build:electron:linux -- --mode test
```
**Features**:
- Test API endpoints
- Staging configurations
- Optimized for testing
- Debug information available
### Production Mode (--mode production)
**Purpose**: Production deployment
**Configuration**: Production environment variables
**Output**: Optimized distribution packages
```bash
# Production build
npm run build:electron -- --mode production
# Production build with specific platform
npm run build:electron:windows -- --mode production
npm run build:electron:mac -- --mode production
npm run build:electron:linux -- --mode production
```
**Features**:
- Production optimizations
- Code minification
- Security hardening
- Performance optimizations
## Platform-Specific Builds
### Windows Builds
**Target Platforms**: Windows 10/11 (x64)
**Package Formats**: NSIS installer, portable executable
```bash
# Windows development build
npm run build:electron:windows -- --mode development
# Windows test build
npm run build:electron:windows -- --mode test
# Windows production build
npm run build:electron:windows -- --mode production
```
**Configuration**:
- NSIS installer with custom options
- Desktop and Start Menu shortcuts
- Elevation permissions for installation
- Custom installation directory support
### macOS Builds
**Target Platforms**: macOS 10.15+ (x64, arm64)
**Package Formats**: DMG installer, app bundle
```bash
# macOS development build
npm run build:electron:mac -- --mode development
# macOS test build
npm run build:electron:mac -- --mode test
# macOS production build
npm run build:electron:mac -- --mode production
```
**Configuration**:
- Universal binary (x64 + arm64)
- DMG installer with custom branding
- App Store compliance (when configured)
- Code signing support
### Linux Builds
**Target Platforms**: Ubuntu 18.04+, Debian 10+, Arch Linux
**Package Formats**: AppImage, DEB, RPM
```bash
# Linux development build
npm run build:electron:linux -- --mode development
# Linux test build
npm run build:electron:linux -- --mode test
# Linux production build
npm run build:electron:linux -- --mode production
```
**Configuration**:
- AppImage for universal distribution
- DEB package for Debian-based systems
- RPM package for Red Hat-based systems
- Desktop integration
## Package-Specific Builds
### AppImage Package
**Format**: Self-contained Linux executable
**Distribution**: Universal Linux distribution
```bash
# AppImage development build
npm run build:electron:appimage -- --mode development
# AppImage test build
npm run build:electron:appimage -- --mode test
# AppImage production build
npm run build:electron:appimage -- --mode production
```
**Features**:
- Single file distribution
- No installation required
- Portable across Linux distributions
- Automatic updates support
### DEB Package
**Format**: Debian package installer
**Distribution**: Debian-based Linux systems
```bash
# DEB development build
npm run build:electron:deb -- --mode development
# DEB test build
npm run build:electron:deb -- --mode test
# DEB production build
npm run build:electron:deb -- --mode production
```
**Features**:
- Native package management
- Dependency resolution
- System integration
- Easy installation/uninstallation
### DMG Package
**Format**: macOS disk image
**Distribution**: macOS systems
```bash
# DMG development build
npm run build:electron:dmg -- --mode development
# DMG test build
npm run build:electron:dmg -- --mode test
# DMG production build
npm run build:electron:dmg -- --mode production
```
**Features**:
- Native macOS installer
- Custom branding and layout
- Drag-and-drop installation
- Code signing support
## Environment Configuration
### Environment Variables
**Development Environment**:
```bash
VITE_API_URL=http://localhost:3000
VITE_DEBUG=true
VITE_LOG_LEVEL=debug
VITE_ENABLE_DEV_TOOLS=true
```
**Testing Environment**:
```bash
VITE_API_URL=https://test-api.timesafari.com
VITE_DEBUG=false
VITE_LOG_LEVEL=info
VITE_ENABLE_DEV_TOOLS=false
```
**Production Environment**:
```bash
VITE_API_URL=https://api.timesafari.com
VITE_DEBUG=false
VITE_LOG_LEVEL=warn
VITE_ENABLE_DEV_TOOLS=false
```
### Build Configuration
**Vite Configuration** (`vite.config.electron.mts`):
```typescript
export default defineConfig(({ mode }) => {
const env = loadEnv(mode, process.cwd(), '');
return {
mode,
build: {
outDir: 'dist',
emptyOutDir: true,
sourcemap: mode === 'development',
minify: mode === 'production'
},
define: {
__DEV__: mode === 'development',
__TEST__: mode === 'test',
__PROD__: mode === 'production'
}
};
});
```
**Electron Builder Configuration** (`electron-builder.config.json`):
```json
{
"appId": "app.timesafari.desktop",
"productName": "TimeSafari",
"directories": {
"buildResources": "resources",
"output": "dist"
},
"files": [
"assets/**/*",
"build/**/*",
"capacitor.config.*",
"app/**/*"
]
}
```
## Build Scripts Reference
### Main Build Scripts
```bash
# Development builds
npm run build:electron:dev # Development build and run
npm run build:electron --dev # Development build only
# Testing builds
npm run build:electron:test # Test environment build
# Production builds
npm run build:electron:prod # Production environment build
```
### Platform-Specific Scripts
```bash
# Windows builds
npm run build:electron:windows # Windows production build
npm run build:electron:windows:dev # Windows development build
npm run build:electron:windows:test # Windows test build
npm run build:electron:windows:prod # Windows production build
# macOS builds
npm run build:electron:mac # macOS production build
npm run build:electron:mac:dev # macOS development build
npm run build:electron:mac:test # macOS test build
npm run build:electron:mac:prod # macOS production build
# Linux builds
npm run build:electron:linux # Linux production build
npm run build:electron:linux:dev # Linux development build
npm run build:electron:linux:test # Linux test build
npm run build:electron:linux:prod # Linux production build
```
### Package-Specific Scripts
```bash
# AppImage builds
npm run build:electron:appimage # Linux AppImage production build
npm run build:electron:appimage:dev # AppImage development build
npm run build:electron:appimage:test # AppImage test build
npm run build:electron:appimage:prod # AppImage production build
# DEB builds
npm run build:electron:deb # Debian package production build
npm run build:electron:deb:dev # DEB development build
npm run build:electron:deb:test # DEB test build
npm run build:electron:deb:prod # DEB production build
# DMG builds
npm run build:electron:dmg # macOS DMG production build
npm run build:electron:dmg:dev # DMG development build
npm run build:electron:dmg:test # DMG test build
npm run build:electron:dmg:prod # DMG production build
```
### Direct Script Usage
All npm scripts use the underlying `./scripts/build-electron.sh` script:
```bash
# Direct script usage examples
./scripts/build-electron.sh --dev # Development build
./scripts/build-electron.sh --test # Test build
./scripts/build-electron.sh --prod # Production build
./scripts/build-electron.sh --prod --windows # Windows production
./scripts/build-electron.sh --test --appimage # Linux AppImage test
./scripts/build-electron.sh --dev --mac # macOS development
./scripts/build-electron.sh --prod --dmg # macOS DMG production
```
### Utility Scripts
```bash
# Cleanup scripts
npm run clean:electron # Clean Electron build artifacts
# Development scripts
npm run electron:dev # Start development server
npm run electron:dev-full # Full development workflow
```
## Build Output Structure
### Development Build
```
electron/
├── app/ # Web assets
├── build/ # Compiled TypeScript
├── dist/ # Build artifacts (empty in dev)
└── node_modules/ # Dependencies
```
### Production Build
```
electron/
├── app/ # Web assets
├── build/ # Compiled TypeScript
├── dist/ # Distribution packages
│ ├── TimeSafari.exe # Windows executable
│ ├── TimeSafari.dmg # macOS installer
│ ├── TimeSafari.AppImage # Linux AppImage
│ └── TimeSafari.deb # Debian package
└── node_modules/ # Dependencies
```
## Troubleshooting
### Common Build Issues
**TypeScript Compilation Errors**:
```bash
# Clean and rebuild
npm run clean:electron
cd electron && npm run build
```
**Native Module Issues**:
```bash
# Rebuild native modules
cd electron && npm run build
```
**Asset Copy Issues**:
```bash
# Verify Capacitor sync
npx cap sync electron
```
**Package Creation Failures**:
```bash
# Check electron-builder configuration
# Verify platform-specific requirements
# Check signing certificates (macOS/Windows)
```
### Platform-Specific Issues
**Windows**:
- Ensure Windows Build Tools installed
- Check NSIS installation
- Verify code signing certificates
**macOS**:
- Install Xcode Command Line Tools
- Configure code signing certificates
- Check app notarization requirements
**Linux**:
- Install required packages (rpm-tools, etc.)
- Check AppImage dependencies
- Verify desktop integration
## Performance Optimization
### Build Performance
**Parallel Builds**:
- Use concurrent TypeScript compilation
- Optimize asset copying
- Minimize file system operations
**Caching Strategies**:
- Cache node_modules between builds
- Cache compiled TypeScript
- Cache web assets when unchanged
### Runtime Performance
**Application Startup**:
- Optimize main process initialization
- Minimize startup dependencies
- Use lazy loading for features
**Memory Management**:
- Monitor memory usage
- Implement proper cleanup
- Optimize asset loading
## Security Considerations
### Code Signing
**Windows**:
- Authenticode code signing
- EV certificate for SmartScreen
- Timestamp server configuration
**macOS**:
- Developer ID code signing
- App notarization
- Hardened runtime
**Linux**:
- GPG signing for packages
- AppImage signing
- Package verification
### Security Hardening
**Production Builds**:
- Disable developer tools
- Remove debug information
- Enable security policies
- Implement sandboxing
**Update Security**:
- Secure update channels
- Package integrity verification
- Rollback capabilities
## CI/CD Integration
### GitHub Actions
```yaml
# Example workflow for Electron builds
- name: Build Electron
run: |
npm run build:electron -- --mode production
npm run build:electron:windows -- --mode production
npm run build:electron:mac -- --mode production
npm run build:electron:linux -- --mode production
```
### Automated Testing
```yaml
# Test Electron builds
- name: Test Electron
run: |
npm run build:electron -- --mode test
# Run automated tests
```
### Release Management
```yaml
# Create releases with assets
- name: Create Release
run: |
# Upload built packages
# Create GitHub release
# Publish to distribution channels
```
## Best Practices
### Development Workflow
1. **Use development mode for local testing**
2. **Test builds in all environments**
3. **Validate packages before distribution**
4. **Maintain consistent versioning**
### Build Optimization
1. **Minimize build dependencies**
2. **Use efficient asset processing**
3. **Implement proper caching**
4. **Optimize for target platforms**
### Quality Assurance
1. **Test on all target platforms**
2. **Validate installation processes**
3. **Check update mechanisms**
4. **Verify security configurations**
---
**Status**: Active implementation
**Last Updated**: 2025-01-27
**Version**: 1.0
**Maintainer**: Matthew Raymer

View File

@@ -0,0 +1,181 @@
# Electron Build Scripts Guide
**Author**: Matthew Raymer
**Date**: 2025-07-11
**Status**: **ACTIVE** - Production Ready
## Overview
This document clarifies the difference between Electron build scripts that create executable packages versus those that run the app directly.
## Script Categories
### 🚀 **Development Scripts (Run App Directly)**
These scripts build the app and then run it immediately for development:
```bash
# Development mode - runs app directly
npm run build:electron:dev
# Test mode - runs app directly
npm run build:electron:test
# Production mode - runs app directly
npm run build:electron:prod
```
### 📦 **Package Build Scripts (Create Executables)**
These scripts build executable packages that can be distributed and run by users:
#### **Platform-Specific Executables**
```bash
# Windows executable (.exe)
npm run build:electron:windows
npm run build:electron:windows:dev
npm run build:electron:windows:test
npm run build:electron:windows:prod
# macOS app bundle (.app)
npm run build:electron:mac
npm run build:electron:mac:dev
npm run build:electron:mac:test
npm run build:electron:mac:prod
# Linux executable
npm run build:electron:linux
npm run build:electron:linux:dev
npm run build:electron:linux:test
npm run build:electron:linux:prod
```
#### **Package Formats**
```bash
# Linux AppImage (portable executable)
npm run build:electron:appimage
npm run build:electron:appimage:dev
npm run build:electron:appimage:test
npm run build:electron:appimage:prod
# Linux DEB package (installable)
npm run build:electron:deb
npm run build:electron:deb:dev
npm run build:electron:deb:test
npm run build:electron:deb:prod
# macOS DMG package (installable)
npm run build:electron:dmg
npm run build:electron:dmg:dev
npm run build:electron:dmg:test
npm run build:electron:dmg:prod
```
## Output Locations
### **Development Scripts**
- Run the app directly in development mode
- No files created for distribution
- App runs immediately after build
### **Package Scripts**
- Create executable files in `electron/dist/`
- Files can be distributed to users
- Users can run the executables by hand
#### **Package Output Examples**
```bash
# AppImage
electron/dist/TimeSafari-1.0.3-beta.AppImage
# DEB package
electron/dist/TimeSafari_1.0.3-beta_amd64.deb
# DMG package
electron/dist/TimeSafari-1.0.3-beta.dmg
# Windows executable
electron/dist/TimeSafari Setup 1.0.3-beta.exe
```
## Usage Examples
### **Development Workflow**
```bash
# Start development (runs app directly)
npm run build:electron:dev
# Test with production build (runs app directly)
npm run build:electron:test
```
### **Distribution Workflow**
```bash
# Build AppImage for Linux distribution
npm run build:electron:appimage:prod
# Build DMG for macOS distribution
npm run build:electron:dmg:prod
# Build Windows installer
npm run build:electron:windows:prod
```
### **Testing Packages**
```bash
# Build test version of AppImage
npm run build:electron:appimage:test
# Test the generated executable
./electron/dist/TimeSafari-1.0.3-beta.AppImage
```
## Key Differences
| Script Type | Purpose | Output | User Action |
|-------------|---------|--------|-------------|
| Development | Run app directly | None | App starts automatically |
| Package | Create executable | `electron/dist/` | User runs executable by hand |
## Best Practices
### **For Development**
- Use `npm run build:electron:dev` for daily development
- Use `npm run build:electron:test` for testing production builds
- App runs immediately after build
### **For Distribution**
- Use `npm run build:electron:*:prod` for production packages
- Test packages before distribution
- Users install/run the generated executables
### **For Testing**
- Use `npm run build:electron:*:test` for test packages
- Verify executables work on target platforms
- Test installation and uninstallation
## Troubleshooting
### **Package Build Issues**
```bash
# Check if package was created
ls -la electron/dist/
# Verify package integrity
file electron/dist/*.AppImage
file electron/dist/*.deb
file electron/dist/*.dmg
```
### **Development Issues**
```bash
# Clean and rebuild
npm run clean:electron
npm run build:electron:dev
```
---
**Last Updated**: 2025-07-11
**Version**: 1.0.3-beta
**Status**: Production Ready

Some files were not shown because too many files have changed in this diff Show More