GPT Review — 20A/20B-P0 Report and Execution Directive

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/20a-20b-p0-search-vector-hygiene-inspection-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-20a-20b-p0-report-and-next-proposal-2026-05-05.md

Verdict

Agent report PASS. Opus assessment is substantially correct.

The evidence supports the primary path:

1. Stop mirroring context-pack into KB/vector.
2. Purge existing KB context-pack mirror after dry-run confirmation.
3. Keep context-pack on filesystem + PG manifest for audit/runtime.
4. Add filesystem retention.
5. Treat 20A search filter as defense-in-depth, not the primary unblock.

Accepted evidence

• 20A filter is feasible as a small patch, but not necessary once KB mirror is removed.
• Context-pack runtime consumers use filesystem, not KB search.
• PG manifest has sufficient audit metadata and checksums.
• FS storage is small and feasible for retention.
• KB mirror is redundant and harmful to search/vector quality.
• Current DOT script accumulates under context-pack/<build_id>/ and has no delete-after-upload.

Correction to Opus execution proposal

Do not gộp E1–E5 into one mutation prompt.

Reason: E1/E3/E5 are different mutation classes:

• E1: patch DOT script;
• E3: bulk KB delete 1,174 docs;
• E5: add cron/filesystem retention.

Bulk delete must have a dedicated dry-run list and a hard approval gate before execution. This is not “lắt nhắt”; it is a safety boundary for destructive operations.

Approved execution structure

20B-P1 — Patch DOT upload behavior only

Goal: stop future pollution.

Actions:

• backup dot-context-pack-build.sh;
• patch KB mirror step 7e to no-op or skip upload entirely;
• do not delete old KB docs;
• do not touch cron;
• verify script syntax;
• optionally run script in dry-run/no-upload mode if supported, otherwise source/static verification only;
• report.

20B-P2 — Dry-run delete plan only

Goal: produce exact deletion manifest.

Actions:

• list all docs with prefix context-pack/;
• count expected 1,174 or explain drift;
• group by build_id;
• verify docs belong only to context-pack mirror;
• verify recovery basis:
  • FS build exists where applicable;
  • PG manifest/checksum exists;
• write delete manifest to KB report;
• no delete.

20B-P3 — Execute KB purge

Only after GPT/User approves P2 manifest.

Actions:

• batch deleteDocument for listed context-pack docs;
• verify prefix count = 0 or expected residual if keeping latest;
• run 7 query search regression;
• report before/after.

20B-P4 — FS retention cron

Goal: keep filesystem archive bounded.

Actions:

• add 7-day retention job for /opt/incomex/context-pack-staging/;
• avoid deleting current symlink target;
• dry-run find first;
• install cron only after dry-run looks safe;
• report.

20A filter patch

Defer until after 20B-P3 unless user wants defense-in-depth immediately.

If done, it should be a separate small patch with regression tests.

Immediate next directive to Opus

Create prompt for 20B-P1 only:

knowledge/dev/laws/dieu44-trien-khai/prompts/20b-p1-stop-context-pack-kb-upload-prompt.md

Prompt must:

1. Read:
   • 20A/20B-P0 report;
   • Opus review;
   • this GPT review.
2. Inspect current script path and verify exact line/section before patch.
3. Backup script with timestamp.
4. Patch only the KB mirror/upload section so future builds do not upload context-pack docs to KB.
5. Preserve filesystem generation and PG manifest publishing.
6. Do not delete existing KB docs.
7. Do not modify retention/cron.
8. Verify:
   • script syntax passes;
   • grep shows no createDocument/upload_document execution path for context-pack KB mirror, or the path is gated disabled;
   • filesystem/PG code paths remain intact.
9. Upload report and HARD STOP.

Hard boundaries for 20B-P1

• no deleteDocument;
• no deindex;
• no bulk cleanup;
• no cron;
• no search API patch;
• no Đ43 patch;
• no service restart unless absolutely required and explicitly stated in prompt;
• no Pack 2C/IU.

Rationale

Stop the leak first. Then produce exact deletion manifest. Then delete with approval. Then add filesystem retention.

This fixes the current vector pollution without creating a new uncontrolled cleanup risk.