# ADHD Scheduling App Starter Project

This is a starter Dart project for an ADHD-focused scheduling application.

The repository intentionally starts with a **pure Dart scheduling core** before adding a full Flutter UI. The hardest part of the product is the scheduling behavior: flexible task shifting, locked time, backlog recovery, recurring availability blocks, and task-state correctness. Keeping that logic independent makes it easier to test and safer to hand off to Codex.

## Intended product direction

- V1/MVP: Today view, backlog/wishlist, quick capture, flexible task pushing, recurring hidden locked blocks, task-state transitions, and a testable scheduling core.
- V2.0: Week/month views, reports, overwhelm shield, drag-and-drop, task history panels.
- Persistence direction: MongoDB is the committed database target. Current V1
  work prepares repository interfaces and document-shaped mappings only; it does
  not add a MongoDB adapter, connection string, Atlas setup, local server
  requirement, accounts, sync, or background service.
- Wishlist/future: Dependencies, context tags, advanced sync, actual MongoDB
  adapter/runtime setup, long-running task behavior decisions.

## Repository layout

```text
.
├── AGENTS.md
├── README.md
├── pubspec.yaml
├── analysis_options.yaml
├── lib/
│   ├── scheduler_core.dart
│   └── src/
│       ├── models.dart
│       ├── scheduling_engine.dart
│       └── task_statistics.dart
├── test/
│   └── scheduling_engine_test.dart
├── Human Documentation/
│   ├── Overall App Design Spec.docx
│   └── Original Chat-Compiled Design Spec.md
└── Codex Documentation/
    ├── README.md
    ├── Current Software Plan/
    └── Archived plans/
```

## Basic commands

Install a Dart SDK that satisfies `pubspec.yaml` first. This starter is a pure
Dart package, so Flutter is not required for the current core/test loop. MongoDB
is the planned persistence target, but no MongoDB service, Atlas account,
connection string, network access, or sync/background process is required for
the current in-memory domain/test loop.

```bash
dart pub get
dart analyze
dart test
```

Run these before committing changes whenever the local environment has Dart
available.

## Documentation

Product and design context belongs in `Human Documentation/`. Codex execution
plans belong in `Codex Documentation/`, with active work under
`Codex Documentation/Current Software Plan/` and finished plans moved to
`Codex Documentation/Archived plans/`.

## Codex handoff

Codex should begin by reading:

1. `AGENTS.md`
2. `Human Documentation/Overall App Design Spec.docx` or the Markdown companion
3. `Codex Documentation/Current Software Plan/README.md`
4. The next numbered block document in `Codex Documentation/Current Software Plan/`

Each completed work block should be committed with a conventional commit message.