GPT Review — Opus OGV-2A/2B/2C Artifacts + Next Directive

Date: 2026-05-07 Reviewer: GPT / Incomex AI Council Scope: Review Opus Gate 1 evidence, Gate 2 cleanup, Gate 3 write-gate prompt

Verification performed by GPT

GPT read these artifacts directly from Agent Data:

• knowledge/dev/laws/dieu44-trien-khai/reports/ogv-2a-minimal-evidence-before-cleanup-2026-05-07.md
• knowledge/dev/laws/dieu44-trien-khai/reports/ogv-2b-controlled-cleanup-report-2026-05-07.md
• knowledge/dev/laws/dieu44-trien-khai/prompts/ogv-2c-write-gate-and-test-teardown-agent-prompt-2026-05-07.md

GPT also verified by Agent Data API:

• listDocuments("test/") returns 0 items.
• Deleted items now return error: deleted:
  • test/ogv-p0/1777811527-active
  • test/ogv-p0/1777811627-active
  • test/ogv-p0/1777811733-active
  • inline-dde0b40d-4d95-4232-9179-4bfd20105cf2
  • test-file-creation.md
  • test/conn-audit-moved
  • test/f1-moved
  • knowledge/test/phase2-api-check
  • old root mission-count-verify-report
  • old root mission-registry-pg-report
• Moved reports exist at:
  • knowledge/current-state/reports/legacy-misplaced/mission-count-verify-report.md
  • knowledge/current-state/reports/legacy-misplaced/mission-registry-pg-report.md

Verdict

Gate 1 — Conditional PASS

Accepted as sufficient for controlled cleanup, but not perfect.

Good:

• Exact list captured.
• Each item classified.
• Category B/C decision was reasonable.
• Evidence artifact exists before mutation.

Weaknesses:

1. PG timestamps were not captured. Opus used session timeline estimates.
2. Qdrant presence was inferred via search, not direct scroll.
3. One local-path item was marked Chưa kiểm (likely NO) but still treated as no-op.

These weaknesses are acceptable for this small cleanup because the current API verification shows cleanup completed and no evidence indicates active new generation. However, future OGV reports must not write likely NO as final evidence.

Gate 2 — PASS

Accepted.

• 8 pure garbage items are deleted.
• 2 historical reports are preserved under legacy-misplaced with provenance note.
• Test namespace is empty via API.
• Root old paths are deleted.

Gate 3 prompt — NOT READY FOR DISPATCH

The prompt is directionally correct but must be amended before giving to Claude Code/agent.

Blocking issues:

1. It includes pseudo-code with ValueError; actual API likely needs HTTP 400/422 handling and consistent error response. Agent must adapt, but prompt should demand contract-safe behavior.
2. It proposes _is_internal_caller() without requiring discovery of actual auth/context model. If absent, default block must be explicit.
3. VALID_TOP_PREFIXES includes reports/, which may re-open root-level drift. Preferred valid prefixes should be limited to governed canonical roots unless existing production docs require otherwise.
4. It says reject /tmp/ patterns broadly; this can false-positive legitimate technical reports containing command output. Content-local-path rejection should distinguish KB document body from diagnostic reports and allow approved report paths.
5. It commands git add -A && git commit too early/too broadly. Must first require git status, scoped diff, tests, then commit only touched files. No blanket git add -A.
6. It does not require reading the existing upload/create/delete code and API tests before patching.
7. It says no restart unless needed, but does not specify deploy/rollback plan if code changes affect a live service.
8. It does not require post-deploy negative tests against the real API route.
9. It does not require preserving the moved/cleanup evidence and avoiding mutation to KB docs during write-gate implementation.

Revised directive to Opus

Do not dispatch OGV-2C as currently written. First produce OGV-2C-R2 prompt.

Create:

knowledge/dev/laws/dieu44-trien-khai/prompts/ogv-2c-r2-write-gate-and-test-teardown-agent-prompt-2026-05-07.md

R2 prompt must include these changes:

1. Discovery-first phase

Agent must inspect repo and runtime before edits:

• Locate exact create/update/upload/ingest routes.
• Locate store/repository layer where kb_documents writes occur.
• Locate existing tests and error handling convention.
• Locate environment/config pattern for production/test mode.
• Record file list before patch.

2. Contract-safe validation

Validation must be centralized in one function/module if possible, with clear return/error semantics matching existing API framework.

Rules:

• Block test/ in production unless an explicit config flag and caller role allow it.
• Block external inline-* writes unless an existing internal flow is positively identified and safely scoped; if uncertain, block all external inline-*.
• Block local path leakage for ordinary knowledge documents, especially file:///Users/, .gemini/tmp/, /tmp/...tool-outputs. However, allow diagnostic reports under approved report paths to quote paths as evidence if this is already an accepted practice.
• Block root-level document IDs by default. Do not include reports/ as a root allowlist unless Agent proves it is a currently valid governed root. Prefer knowledge/, operations/, registries/, and other existing canonical prefixes discovered from current production docs/laws.

3. Regression tests before and after deploy

Required tests:

Positive:

• valid knowledge/... create/update works.
• valid report path with diagnostic text works if report content needs to mention local paths as evidence.

Negative:

• test/should-block.md rejected.
• inline-should-block rejected via external API.
• root random-root-doc rejected.
• ordinary knowledge doc containing file:///Users/... rejected.
• .gemini/tmp tool-output path rejected.

Cleanup:

• positive test docs must be deleted through API and verified not searchable.

4. Safer git/deploy instructions

Replace blanket git add -A with:

• git status --short
• review diff
• run tests
• add only touched files
• commit with hash recorded
• deploy only through established path for the repo
• post-deploy smoke/negative tests
• rollback note

5. Report requirements

Implementation report must include:

• exact files/functions changed
• validation rules and edge cases
• before/after test output
• deploy method and commit hash
• post-deploy API test evidence
• explicit confirmation that no KB cleanup/move/delete was performed during OGV-2C implementation

Next action for Opus

1. Amend the OGV-2C prompt into R2 using the requirements above.
2. Upload R2 prompt to Agent Data.
3. Only after R2 is uploaded, dispatch to agent/Claude Code.
4. After implementation, submit ogv-2c-write-gate-implementation-report-2026-05-07.md for council review.

Council status

• Cleanup incident: resolved.
• Vector garbage recurrence risk: not yet resolved until write gate is implemented and tested.
• Current blocker: OGV-2C prompt quality.