GPT Review — B3-F1c-f dot-dot-health Hardcode/Auto-scale Audit Prompt — PATCH REQUIRED BEFORE AGENT — 2026-05-13

Scope reviewed

Reviewed Opus B3-F1c-f deliverables:

• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-f-dot-dot-health-hardcode-autoscale-audit-prompt-DRAFT.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3f1c-f-dot-dot-health-hardcode-autoscale-audit-design.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-f-dot-dot-health-hardcode-autoscale-audit-design-report.md revision 1

Related review:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-e-probe-pass-reuse-with-wrapper-hardcode-audit-required-2026-05-13.md

Verdict

Status: PATCH_REQUIRED_BEFORE_AGENT_AUDIT

The audit direction is correct, and the 3 blocking questions are appropriate. However, the prompt regressed on several zero-trust patterns that were already enforced in B3-F1c-c/d/e. Do not dispatch Agent until patched.

Accepted high-level direction

Accepted:

• Audit before wrapper design.
• Focus on whether cron actually runs, whether hardcoded jurisdiction blocks Law 44 usage, and whether registry drift blocks wrapper path.
• Full hardcode classification of dot-dot-health is required.
• Legacy debt can be documented separately if it does not block B3-F1c.

Blocking issue 1 — path and PG access discovery regressed

Prompt Phase 0 uses:

test -f /opt/incomex/dot/bin/dot-dot-health ...
docker exec postgres psql -U directus -d directus -c "SELECT 1"

This repeats earlier assumptions. The previous approved B3-F1c-e prompt already required discovered path variables and PG access discovery.

Required patch:

• Use DOT_HEALTH_PATH=<discovered path> and reference that variable throughout all later phases.
• If multiple candidates exist, block with BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES.
• Discover/confirm PG access path before use. If the known postgres container is used, first confirm it exists and works; otherwise discover via docker ps.
• Add/retain final fields:

dot_dot_health_path_discovered=true|false
pg_access_discovered=true|false
blocked_reason includes BLOCKED_PG_ACCESS_UNDISCOVERABLE and BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES

Blocking issue 2 — dot_tools queries are not schema-first

Prompt Phase 3 uses:

SELECT * FROM dot_tools WHERE code = 'DOT-HEALTH-DOT' OR name ILIKE ...

and Phase 3b uses fixed columns:

SELECT code, name, domain, operation, status FROM dot_tools ...

The earlier probe confirmed these columns, but this audit prompt should remain self-contained and zero-trust. It must not assume dot_tools columns.

Required patch:

• Add dot_tools schema discovery before Phase 3 queries.
• Use confirmed columns only.
• If semantics cannot be mapped, return BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED.
• Avoid SELECT * in report-generating probes; it can expose unrelated metadata and creates unstable output.

Blocking issue 3 — system_health_checks query is not schema-first

Prompt Phase 2b uses fixed columns:

SELECT DISTINCT jurisdiction, count(*) ... FROM system_health_checks WHERE is_active = true

Required patch:

• Add system_health_checks schema discovery before jurisdiction queries.
• Use confirmed columns only.
• If schema insufficient, return BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED.

Blocking issue 4 — direct log grep may expose secrets or too much unrelated data

Prompt Phase 1c uses:

grep -i 'dot-dot-health\|dot_health' /var/log/syslog /var/log/cron 2>/dev/null | tail -10

This is probably low risk, but logs may include environment command lines, paths, or sensitive values. Since the prompt explicitly has a no-secret boundary, it should state output must be redacted and limited to timestamps/status/error snippets relevant to dot-dot-health.

Required patch:

• Add log redaction rule:
  • no tokens, passwords, env var values, full DB URLs, or API keys in KB report;
  • include only timestamp, command basename, exit/error wording, and minimal context.
• Add final field:

log_output_redacted=true|false

Blocking issue 5 — sudo crontab -l may prompt or fail noisily

Prompt says:

sudo crontab -l ...

This may block or produce interactive prompt depending on Agent context. It is read-only, but should be non-interactive.

Required patch:

• Use non-interactive safe form or state:

If sudo requires interaction or is unavailable, skip and report root_crontab_access=UNAVAILABLE; do not hang, do not request passwords.

Add final field:

root_crontab_access=AVAILABLE|UNAVAILABLE|NOT_NEEDED

Blocking issue 6 — cron viability cannot be concluded from grep only

Prompt asks whether cron has ever succeeded, but only greps logs. If logs are rotated/absent, answer may be UNKNOWN. That is acceptable, but decision tree says YES/UNKNOWN continues, which may allow wrapper path even if automatic execution is unproven.

Required patch:

• Separate:
  • cron_config_present=true|false
  • cron_command_parse_compatible=true|false|unknown
  • cron_success_evidence=FOUND|NOT_FOUND|UNKNOWN
  • cron_reliable_for_automation=true|false|unknown
• If parse incompatibility is proven (--local unrecognized), decision must be REPAIR_DOT_DOT_HEALTH_SCHEDULER_FIRST, regardless of old log evidence.
• If success evidence is UNKNOWN but parse compatible, it may be non-blocking but must be flagged.

Blocking issue 7 — hardcode classification output needs machine-readable table fields

Prompt asks for a classification table, but final fields only count categories. To make review actionable, require a KB report table with every literal and exact classification.

Required patch:

• Require table columns:

value_or_pattern | source | line_or_location | current_storage | classification | scale_impact | blocks_b3f1c | recommended_action

• Require blocks_b3f1c=true|false per item.

Blocking issue 8 — final blocked reasons are missing

Final fields include status but not structured blocked_reason.

Required patch:

• Add:

blocked_reason=<none|BLOCKED_PG_ACCESS_UNDISCOVERABLE|BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES|BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED|BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED|BLOCKED_CRON_PARSE_INCOMPATIBLE|BLOCKED_CRON_RELIABILITY_UNKNOWN|BLOCKED_NEEDS_DESIGN>
compiled_from_assumptions=false

Required Opus response

Patch prompt/design/report and return:

b3f1c_f_audit_prompt_patch_status=PASS|PARTIAL|BLOCKED
path_and_pg_access_discovery_restored=true|false
dot_tools_schema_first_added=true|false
system_health_checks_schema_first_added=true|false
log_redaction_added=true|false
root_crontab_noninteractive_added=true|false
cron_reliability_fields_added=true|false
hardcode_table_fields_strengthened=true|false
blocked_reason_fields_added=true|false
compiled_from_assumptions_field_added=true|false
agent_audit_allowed=false_until_gpt_review
wrapper_design_allowed=false
system_health_checks_insert_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=GPT_REVIEW_PATCHED_B3F1C_F_AUDIT_PROMPT

Governance status

b3f1c_f_audit_prompt_review_status=PATCH_REQUIRED_BEFORE_AGENT_AUDIT
agent_audit_allowed=false
wrapper_design_allowed=false
system_health_checks_insert_allowed=false
dot_tools_mutation_allowed=false
scheduler_mutation_allowed=false
new_dot_creation_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_PATCH_B3F1C_F_AUDIT_PROMPT