GPT Review — OGV-2C R2 Prompt Dispatch Decision

Date: 2026-05-07 Reviewer: GPT / Incomex AI Council Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/ogv-2c-r2-write-gate-and-test-teardown-agent-prompt-2026-05-07.md

Verdict

PASS WITH SMALL DISPATCH ADDENDUM.

R2 fixed the major blockers from R1 and is suitable for agent dispatch after Opus adds or verbally includes the addendum below.

Accepted improvements:

1. Discovery-first phase is now mandatory.
2. Error handling must follow actual framework convention.
3. _is_internal_caller() ambiguity is removed; agent must discover real internal/external boundary or block external inline-*.
4. reports/ is removed from default allowlist.
5. /tmp/ false-positive risk is reduced by bare-path detection and length threshold.
6. git add -A is removed; scoped add required.
7. Deploy, rollback, and post-deploy verification are included.
8. Scope guard now says no cleanup/move/delete KB documents.

Council view on Opus's bare-path detection choice

Accepted.

The R2 bare-path heuristic is better than a broad /tmp/ content ban. It targets the actual observed failure mode: a short document whose entire body is a local file path. It should allow long diagnostic reports that discuss /tmp, /Users, or tool-output paths as evidence.

Required caution: agent must implement this as a validation helper with tests, not as scattered regex checks.

Dispatch addendum — must include with R2

Before sending to Claude Code/agent, add these clarifications:

A. Payload schema discovery

The prompt uses path in examples, but the actual API/tooling may use document_id, id, or another field name. Agent must discover and use the real request/response schema before writing tests or curl commands.

Do not hardcode path unless Phase 0 proves it is the live API field.

B. HTTP status verification

Do not use jq .status_code unless the API really returns a status_code field in the JSON body. Prefer curl status capture:

curl -s -o /tmp/ogv2c_response.json -w "%{http_code}" ...
cat /tmp/ogv2c_response.json | jq .

PASS/FAIL must be based on actual HTTP code plus response body.

C. Config discipline

If no test-mode env/config exists, do not casually introduce KB_TEST_MODE as an always-on production flag. Prefer default-deny in production and only add a documented config if tests or existing architecture require it.

Any new env var must be documented and must default to safe production behavior.

D. Valid prefix discovery

Default allowlist can start with knowledge/, operations/, registries/, but agent must verify existing governed prefixes from production data/code. If other canonical roots exist, agent must report them and justify inclusion. Do not include reports/ merely for convenience.

E. Scope wording for test cleanup

The rule “Không cleanup/move/delete KB documents” means no cleanup/move/delete of pre-existing production KB content during OGV-2C. It does not prohibit deleting the temporary positive test documents created by OGV-2C itself. Those must be cleaned up and verified.

F. Avoid deleting-path code changes

Agent may call existing delete API to remove OGV-2C positive test docs. Agent must not modify delete-path implementation unless Phase 0 finds that positive test cleanup cannot be performed through existing safe API; in that case STOP and report.

Required execution path

1. Opus dispatches OGV-2C R2 with the addendum above.
2. Agent executes Phase 0 first and may stop if live API/schema/error conventions differ materially from prompt assumptions.
3. Agent uploads implementation report:

knowledge/dev/laws/dieu44-trien-khai/reports/ogv-2c-write-gate-implementation-report-2026-05-07.md

4. Opus must not mark vector recurrence risk closed until GPT/User review the implementation report and post-deploy negative tests.

Final status

• OGV-2A evidence: accepted with noted weakness.
• OGV-2B cleanup: accepted.
• OGV-2C R2 prompt: approved for dispatch with addendum.
• Incident cleanup is closed; recurrence prevention remains open until implementation report PASS.