Files
KArtSell.Aegis/docs/CURRENT/PHASE-1_EXECUTION_EVIDENCE_PLAN.md
T
kjh2064 258eb7ef2f
ci / static (push) Failing after 8s
ci / backend (push) Failing after 1s
ci / publish (push) Has been cancelled
ci / frontend (push) Has been cancelled
Build & Test with Secrets / build (push) Failing after 1s
deploy / deploy (push) Successful in 2m46s
Build & Test with Secrets / security-scan (push) Failing after 7s
Build & Test with Secrets / frontend (push) Successful in 3m49s
deploy / notify (push) Successful in 1s
Build & Test with Secrets / notification (push) Failing after 1s
PHASE-1-SHADOW-RUN: define concrete execution evidence plan
2026-08-06 14:31:43 +09:00

117 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Phase 1 Execution Evidence Plan
## Objective
Create the evidence required to move `PHASE-1-SHADOW-RUN` from `BLOCKED` to `RUNNING`, using shadow-only / `EVALUATION_ONLY` execution. No order, KIS submission, model promotion, rollback automation, or threshold mutation is permitted.
## Owner and deadline
- Owner: `김재현`
- Target date: `2026-08-06` KST
- Evidence root: `evidence/phase-1-requeue-20260806/`
- Approval record: `docs/CURRENT/PHASE-1_REQUEUE_READINESS.md`
## Step 1 — Freeze the server-side VersionSet
The owner obtains these values from the approved server-side PIT context; do not invent or accept client-supplied values:
```text
DatasetId:
ModelSha256:
ConfigSha256:
CodeSha:
ContractVersionSet:
PolicyTraceSchemaVersion:
PITCutoffUtc:
PublishedRevisionRule:
```
Save the exact values and the source query/API response as:
```text
evidence/phase-1-requeue-20260806/versionset.json
evidence/phase-1-requeue-20260806/versionset-command.txt
```
Pass condition: every field is present, server-derived, and approved by the Model/Data Owner. A missing field stops the procedure.
## Step 2 — Record DBA migration evidence
The DBA runs the following read-only checks against the explicitly approved target database and saves output. The database name must be checked before execution.
```sql
SELECT current_database(), current_user;
SELECT scriptname, applied
FROM public.__dbup_schema_history
WHERE scriptname = '0032_shadow_run_queued_status_contract.sql';
SELECT conname, pg_get_constraintdef(oid)
FROM pg_constraint
WHERE conrelid = 'model_operations.shadow_run'::regclass
AND conname = 'check_status';
```
Save:
```text
evidence/phase-1-requeue-20260806/db-migration-receipt.txt
evidence/phase-1-requeue-20260806/db-migration-receipt.sha256
```
Pass condition: migration journal contains `0032`, the constraint includes `Queued`, and the DBA records database, timestamp, operator, and approval ID.
## Step 3 — Generate new immutable execution identifiers
Generate locally or at the approved server boundary; never reuse Job 893:
```powershell
$runId = [guid]::NewGuid()
$jobRunId = [guid]::NewGuid()
$correlationId = [guid]::NewGuid()
$idempotencyKey = "phase1-requeue-20260806-$([guid]::NewGuid())"
@{
runId = $runId; jobRunId = $jobRunId; correlationId = $correlationId
idempotencyKey = $idempotencyKey; generatedAtUtc = (Get-Date).ToUniversalTime().ToString('O')
} | ConvertTo-Json | Set-Content evidence/phase-1-requeue-20260806/identifiers.json
```
Record the generated values in the approval form before enqueue. Do not log credentials or tokens.
## Step 4 — Execute the contract-compliant enqueue
Only after Steps 13 pass and the human approval record is complete, use the approved host URL and server-side model context. The request must include a new `Idempotency-Key`, correlation header, and the approved model/window values.
```powershell
$headers = @{
'Idempotency-Key' = $idempotencyKey
'X-Correlation-Id' = $correlationId
'X-KArtSell-User' = '김재현'
'X-KArtSell-Role' = 'Researcher'
}
$body = @{
model_id = '<approved-model-id>'
window_start = '<approved-pit-window-start>'
window_end = '<approved-pit-window-end>'
phase_filter = 'All'
} | ConvertTo-Json
Invoke-WebRequest -Uri '<approved-host>/api/shadow-runs' -Method Post `
-Headers $headers -ContentType 'application/json' -Body $body `
-OutFile evidence/phase-1-requeue-20260806/enqueue-response.json
```
Pass condition: HTTP 202, a new `run_id`, a new `job_id`, and `status=Queued`. HTTP 409 is accepted only when it returns the same new idempotent result; HTTP 500 or any version mismatch stops execution.
## Step 5 — Preserve observation evidence
Poll only the returned new `run_id`. Save raw responses and timestamps under the evidence root. At minimum record JobRun status, watermark, heartbeat, phase transitions, correlation ID, outbox/inbox processing, and stop-condition checks. Do not claim completion until the actual artifacts exist.
## Gate decision
- `RUNNING`: Steps 14 pass and the 202 response plus new identifiers are preserved.
- `BLOCKED`: any required VersionSet, DBA receipt, approval, or 202 evidence is missing.
- `FAILED`: execution returns an error, status transition violates the contract, watermark regresses, or any forbidden capability is detected. Preserve evidence and stop; do not mutate historical records.
This plan is an execution aid, not evidence itself. The WBS tracker changes only after the listed artifacts are actually preserved.