<!-- SPDX-FileCopyrightText: 2026 FocusFlow contributors -->
<!-- SPDX-License-Identifier: AGPL-3.0-only -->


# Task Pushing 01 Block 06 — Destination Scheduling Rules

**Status:** Complete.
**Goal:** Verify or adjust backend push scheduling so destination behavior exactly
matches the requested product rules.

---

## Block outcome

After this block, the scheduler/application layer should guarantee no-overlap,
no-before-now push placement. UI tests should not need to compensate for backend
semantics.

---

## Chunk 6.1 — Verify Push to next behavior

### Tasks

1. Add scheduler-core/application tests for a past incomplete flexible task with
   an open slot later today.
2. Assert Push to next places the task in the later-today slot.
3. Add a test where no later-today slot exists.
4. Assert the result is either the next backend-supported future slot or a clear
   no-fit result, depending on confirmed scheduler horizon rules.
5. Assert placement never overlaps required, locked, or already-planned tasks.
6. Assert placement never lands before current owner-local time.

### Acceptance criteria

- Push to next satisfies same-day-if-available behavior.
- Push to next never moves into the past.
- Any no-fit response keeps the original task safe and persisted.

---

## Chunk 6.2 — Verify Push to tomorrow behavior

### Tasks

1. Add tests for targeting the next owner-local civil day relative to current
   time.
2. Assert placement uses the first valid no-overlap slot on that day.
3. Add locked/required-time conflicts and assert they are skipped.
4. Add a no-fit tomorrow case and assert the task remains safe with a clear
   failure/no-fit result.
5. Confirm selected historical/future date does not accidentally redefine
   `tomorrow` for overdue recovery.

### Acceptance criteria

- Push to tomorrow targets real owner-local tomorrow.
- Push to tomorrow avoids overlaps.
- Push to tomorrow does not depend on the currently selected review date unless
  Block 01 deliberately chose that behavior.

---

## Chunk 6.3 — Adjust backend only if tests reveal semantic gaps

### Tasks

1. If existing commands already pass the tests, do not rewrite them.
2. If Push to next can place before current time, add an application/core anchor
   parameter rather than filtering in UI.
3. If Push to tomorrow means top-of-queue but not first open slot, update core
   semantics or add a clearly named command matching the requested behavior.
4. If no-fit behavior is ambiguous, return an `ApplicationFailure`/notice that
   the existing UI can show calmly.
5. Update command/read-hint behavior only as needed to refresh affected dates.

### Acceptance criteria

- Any semantic fix lives in scheduler/application code, not widgets.
- Existing push tests still pass or are updated for the new explicit semantics.
- New behavior is covered before UI integration is considered complete.

---

## Chunk 6.4 — Verify scheduling-change accounting

### Tasks

1. Assert manually pushed selected task records the correct activity/statistics.
2. Assert automatically moved downstream tasks record automatic-push activity.
3. Assert Push to backlog records moved-to-backlog activity and any explicit
   freshness reset metadata added in Block 07.
4. Ensure duplicate operation ids remain idempotent/rejected according to the
   application command contract.

### Acceptance criteria

- Push activity/statistics remain durable and consistent.
- Downstream movement is auditable.
- Duplicate operation behavior remains safe across close/reopen.

---

## Block acceptance criteria

- Push destination scheduling rules are guaranteed by backend tests.
- No-overlap and no-before-now behavior is proven.
- No-fit behavior keeps tasks safe.
- Activity/statistics accounting remains consistent.

## Validation after block

```sh
cd packages/scheduler_core
dart analyze
dart test
cd ../scheduler_persistence_sqlite
dart test
```
