PROJECT_PROMPT.md

SolidPrivacy Scrub — Project Prompt / Worker Instructions

This file is the full project prompt for workers on SolidPrivacy Scrub.

For ChatGPT Project Instructions, use the shorter bootstrap prompt in PROJECT_PROMPT_SHORT.md. The short prompt points workers back to this file and the other central control files.

---

Repository

Work only in:

solidprivacy-nl/scrub

Do not modify unrelated repositories. If the active repository is not solidprivacy-nl/scrub, stop and report the mismatch.

---

Source of truth

GitHub is the source of truth.

Always start by reading, in this order:

1. PROJECT_PROMPT.md
2. ROADMAP.md
3. WORKPACKAGES.md
4. CHANGELOG.md

Use these files as follows:

• PROJECT_PROMPT.md = full worker rules and operating model.
• PROJECT_PROMPT_SHORT.md = short bootstrap prompt suitable for ChatGPT Project Instructions.
• ROADMAP.md = product vision, strategic direction, phase order, bigger picture.
• WORKPACKAGES.md = current executable workpackages, dependencies, parallelization rules.
• CHANGELOG.md = historical implementation log.

Do not invent a new direction if it conflicts with these files. If the roadmap is stale, unclear, or internally inconsistent, report that first.

---

Current way of working

Work in small, testable workpackages.

For each workpackage:

1. Confirm the workpackage title and scope.
2. Check dependencies in WORKPACKAGES.md.
3. Prefer helper modules and tests before UI changes.
4. Avoid parallel edits to the same UI patch area.
5. Add or update tests where meaningful.
6. Update CHANGELOG.md for implementation history.
7. Update ROADMAP.md only when strategy, phase status, or sequence changes.
8. Update WORKPACKAGES.md when execution status, dependencies, or next workpackages change.
9. End with a handover summary.
10. Write the handover summary to handover/workpackages/.

---

Parallelization rule

Safe to do in parallel:

• helper modules;
• tests;
• specifications;
• documentation;
• non-UI architecture work.

Do not do in parallel without explicit coordination:

• presidio_streamlit.py;
• fix_streamlit_nested_expanders.py;
• review table UI flow;
• export/download UI flow;
• shared workflow state.

When in doubt, keep UI integration sequential.

---

Testing and sync

After implementation:

1. Confirm GitHub Actions tests are green.
2. Confirm GitHub to Hugging Face sync is green.
3. Ask the coordinator/user to verify the Hugging Face app when visual or UI behavior changed.
4. Do not claim functional success until either tests prove it or the user confirms it in the app.

---

Changelog discipline

Every meaningful change must be reflected in CHANGELOG.md.

Include:

• workpackage/version;
• status;
• purpose;
• files added/changed;
• main changes;
• tests;
• validation status;
• intentionally not changed.

Keep the changelog human-readable.

---

Handover discipline

Every worker must end with a handover summary.

The handover must explicitly state:

• repository worked in;
• workpackage title;
• status;
• files added;
• files changed;
• tests added/updated;
• validation status;
• GitHub Actions status if known;
• Hugging Face sync status if known;
• app verification status if known;
• remaining risks or follow-up actions;
• next recommended step.

Also write the same handover summary to:

handover/workpackages/

Use this filename format:

handover/workpackages/YYYYMMDD_HHMM_<workpackage_slug>.md

Example:

handover/workpackages/20260607_1430_v12_5_final_review_summary.md

The coordinator can use this directory to automatically read worker updates.

Handover template

# Handover — <Workpackage title>

Repository: solidprivacy-nl/scrub  
Status: <completed / implemented / blocked / pending verification>

## Summary

<Short explanation of what was done.>

## Files added

- ...

## Files changed

- ...

## Tests

- ...

## Validation

- GitHub Actions: <green/red/unknown>
- Hugging Face sync: <green/red/unknown>
- App verification: <confirmed/pending/not applicable>

## Notes / risks

- ...

## Next recommended step

- ...

---

Safety and quality rules

• Do not remove existing functionality unless the workpackage explicitly requires it.
• Do not silently change export semantics.
• Do not weaken privacy or review controls.
• Do not introduce cloud dependencies for document processing unless explicitly approved.
• Do not store secrets, tokens, or real personal data.
• Use synthetic data only.
• Preserve legal context: replace sensitive values, not legal meaning.
• Be honest about uncertainty, failed validation, or incomplete implementation.

---

Product direction

The current product direction is:

Scrub → Review → Scrub Key → AI → Reinsert → Export → Audit

The first market is Dutch legal documents.

The broader direction is a local-first Dutch privacy scrubber for professional confidential documents.

The immediate development line is v12 Review UX, followed by v13 Scrub Key / Reinsert.