# Continue a project without rewriting its past

Make a manager update from Friday's materials, save it, then continue from that result when new information arrives. The worked example follows a fictional equipment-lending desk at North Quay Learning Centre. All people, dates and records are invented. The supplied reference outputs are designed examples, not customer records or observed agent performance.

## Start with Friday

Use your own agent that can read attachments and create downloadable files. Give it only these three inputs and the task in [instruction.txt](instruction.txt):

- [Context and decision responsibilities](inputs/context.md)
- [Friday meeting notes](inputs/friday-meeting.md)
- [Friday tracker](inputs/friday-tracker.csv)

Do not upload this whole folder as the first task. It also contains later information and designed answers. You do not need to read the technical contract, use the sample decision IDs or run Python to start.

The task asks for three files in `friday-output/`: a readable manager update, editable project state and a note for whoever continues the work. Open the update and check that:

- Every workstream is covered, with its owner and source.
- A ready file, requested date or offer of help has not become an approval.
- Pending decisions, missing information and next actions are easy to find.

Ask the agent to correct unsupported claims, then save all three accepted files. Keep this Friday snapshot unchanged.

## Continue only after saving Friday

Give the agent your saved Friday files, [Monday's new information](inputs/monday-changes.md) and [continue.txt](continue.txt). Ask for a separate `monday-output/`, not a replacement for Friday.

Read the new update alongside the old one. Can you see what changed, what stayed the same, why it changed and what still needs a decision? Check each change against the new source. All cutoffs use Singapore time.

## Bring your own project

Replace the fictional inputs with materials you are allowed to share with your chosen service. Name the reader, decision owners and cutoff. Keep the first accepted result and supply it with the next batch of information. Use your own work labels and file names; the sample's identifiers are not a business standard.

This is a complete worked case with adaptable originals, not a guarantee that any project's update will be correct or quicker. Review the result before relying on it. The exercise does not authorize contacting anyone, spending money, printing or announcing a launch.

## Inspect the complete teaching example

The [case page](https://codexwork.com/guide/cases/operations-week/) shows the designed before-and-after results. In this folder, `reference/episode-01/` and `reference/episode-02/` preserve the original editable examples. These are answers to inspect, not extra facts to give the first task.

For exact five-file reproduction, use [CASE.md](CASE.md), [chain.json](chain.json), [acceptance.md](acceptance.md) and [metadata.json](metadata.json). That technical contract uses fixed decision/action/work IDs and a different output shape from the short start above. The original `check.py` tests only that fixture:

    python3 check.py --episode 1 --outputs friday-fixture-output
    python3 check.py --episode 2 --outputs monday-fixture-output
    python3 check.py --self-test

Python 3 is needed only for these optional checks. A pass establishes fixture compatibility, not the correctness of an arbitrary project's sources or prose. Do not run it against the short task's three-file result and treat a failure as a business judgment.
