# Report partial progress without promising a finished outcome

Manual worksheet; invented situation, no automatic product import.

## Owned work

- State the accepted slice — Interface owner — The approved interface result is identified without extending it to migration.
- Expose the delivery boundary — Migration owner — The cancelled-record fixture defines the remaining gap.
- Set the next review — Delivery lead — The receiving reviewer and Thursday checkpoint are named.

## Workflow questions

### Can I still show a completion percentage?

Yes if its denominator is clear, but retain the unmet delivery condition beside it.

### Must we hide the finished interface?

No. Credit the actual accepted slice without treating it as the whole workflow.

### What belongs in TeamBoost?

Keep the interface and migration work identifiable, update the migration owner and explain the delivery boundary in the task-linked reporting note. Confirm available fields before adopting that structure.

## Job to be done

When visible screens are finished but the full workflow is not, I want to explain the accepted slice so stakeholders can decide without assuming delivery.

The new interface passes its review. Migration still drops cancelled records, so the full customer workflow is not ready.

### Recognizable symptoms

- A large done count hides a required unfinished slice.
- Stakeholders interpret UI completion as usable delivery.
- Remaining work is described as small instead of owned.

### Shortcut that fails

Adding a percentage or saying nearly done does not explain whether the required outcome works.

### Before

The interface is done. The project is basically complete; migration is a small follow-up.

### After — invented worked answer

Progress: the interface review passed. Delivery remains pending because migration does not preserve cancelled records. The migration owner will correct the supplied fixture and return it for review on Thursday. No end-to-end delivery is claimed; the next update will state the fixture result.

### Conditional next moves

- If One required slice remains open: Report partial acceptance. Most visible work cannot stand in for the required full outcome.
- If The completed slice is independently usable: Offer it within its agreed limits. Usability of that slice does not certify the remaining workflow.
- If All receiving conditions pass: State the accepted full outcome. Keep the acceptance evidence attached to the claim.

### TeamBoost route — confirm account availability

- Separate the work slices: Keep accepted interface work distinct from the open migration correction. Your check: Labels reflect agreed acceptance evidence, not visual polish.
- Explain the remaining gap: Attach or reference the cancelled-record fixture and requested correction. Your check: The receiver verifies that the fixture is relevant and accessible.
- Prepare the progress update: Use a dated note that states partial acceptance and the next receiving check. Your check: A human decides whether the full delivery boundary passed.

### Success check

The recipient can distinguish the accepted interface from the unfinished delivery requirement and identify the next evidence event.

### Editable draft facts

- Accepted slice [accepted]: Interface review passed — State exactly what was accepted.
- Remaining required outcome [remaining]: Migration must preserve cancelled records — Use the outcome, not a vague percent.
- Review evidence [proof]: Cancelled-record fixture — Name a check the receiver can inspect.
- Remaining owner [owner]: Migration owner — Keep responsibility explicit.
- Next receiving checkpoint [next]: Thursday fixture review — Use the next evidence event.

### Draft pattern — replace every placeholder

```text
Progress update
Accepted: {accepted}.
Still required: {remaining}.
Evidence to inspect: {proof}.
Owned by: {owner}.
Next receiving check: {next}.
Full delivery remains open until the required outcome is evidenced.
```

### Limits

The illustrated slices and review date are fictional. This guide does not infer completion from task counts or promise a delivery date.

Local text preparation only; no workspace read, task creation, send or approval. Source interfaces do not establish account availability or live feature completion.
