Skylight R Shiny Development

A development assistant for working with Skylight, an R Shiny package for a family calendar display optimized for iPad. The package integrates Google Calendar, includes an AI chat assistant (Claude via ellmer), weather widget, and offline support via DuckDB caching.

Instructions

When working with the Skylight codebase, follow these guidelines:

Development Workflow

1. **Load and run the package**:

- Use `devtools::load_all()` to load the package for development

- Use `run_app()` to start the Shiny application

- The app initializes DuckDB on startup

2. **Testing**:

- Run all tests with `devtools::test()`

- Run individual test files with `testthat::test_file("tests/testthat/test-utils_dates.R")`

- Replace the filename with the specific test file you need to run

3. **Documentation and checks**:

- Rebuild documentation with `devtools::document()`

- Check package integrity with `devtools::check()`

Architecture Understanding

**Entry Point**: The application starts via `run_app()` in `R/run_app.R`

**Core Structure**:

**Module Pattern**: Each module uses `mod_*_ui()` and `mod_*_server()` functions. View modules (week, month, day, agenda) receive shared reactive data:

**Key Subsystems**:

**Demo Mode**: When Google credentials are missing, the app runs in demo mode using `generate_sample_events()` and `generate_sample_calendars()` from `utils_demo.R`

Environment Variables

**Required**:

**Optional**:

Docker Deployment

Build and run with docker-compose:

```bash

docker-compose up -d # Start

docker-compose logs -f # View logs

docker-compose down # Stop

```

Create a `.env` file with required environment variables:

```

ANTHROPIC_API_KEY=your_key

GOOGLE_CLIENT_ID=your_id

GOOGLE_CLIENT_SECRET=your_secret

GEMINI_API_KEY=your_key # Optional

OPENWEATHER_API_KEY=your_key # Optional

```

Data is persisted in Docker volumes:

Code Modifications

When modifying code:

1. Understand which subsystem you're working in (auth, calendar, database, chat, etc.)

2. Follow the existing module pattern for UI/server separation

3. Ensure offline resilience by using cached data appropriately

4. Update tests in `tests/testthat/` for any new functionality

5. Run `devtools::document()` after adding or modifying exported functions

6. Run `devtools::check()` before committing changes

Issue Tracking

This project uses **bd** (beads) for issue tracking. Refer to AGENTS.md for workflow details.

Examples

**Running the app locally**:

```r

devtools::load_all()

run_app()

```

**Testing a specific utility**:

```r

testthat::test_file("tests/testthat/test-utils_dates.R")

```

**Checking package after changes**:

```r

devtools::document()

devtools::check()

```

Constraints