INT03 exact rehearsal: frozen plan, legacy manifest, and policy are mutually incompatible

[hjcud]

Reproduction boundary

Isolated local rehearsal for root #447 used root 0728ca0fd85b1c4794306aeb9dc3901a03b406d8, backtest-engine e58b92df45a494b619327e3d222a08c7edea7e19, and read-only Development evidence for run dcc110d7-6cb2-3909-bb9f-623b21ac90bf. No Development DB/SQS/worker write or restart was performed.

The exact immutable objects were downloaded by VersionId and all 8 market Parquet SHA-256 values plus the feature Parquet SHA-256 matched S3 and database metadata. The feature object decoded through the production binder with 34,376 rows and matched locked result hash sha256:cf7f43ede602740e5a7879c759a19a4b77fac4803b5861628b1fa89e76d2ee3a. The legacy dataset hash matched the legacy market-loader/1.0.0 manifest formula.

New blockers after #77

The exact frozen input set still cannot start simulation:

1. The persisted compiled plan has initialCashAmount=100000.00; the current v2 plan schema requires exactly 8 fractional digits. The declared checksum recomputes correctly, so rewriting the literal would change the frozen plan.
2. After diagnostic normalization only, the same plan is rejected because instrumentCatalogVersion=us-supported-universe:2026-08-09; this runtime implements us-supported-universe:2026-07-31. That field is also checksum-covered.
3. The pinned legacy manifest hash 08a848... is a valid legacy loader manifest hash, not the current canonical_dataset_hash over upgraded central rows. ParquetMarketDataReader therefore rejects the reconstructed manifest after chore: advance backend through COM07 #77 resolves the legacy manifest_id= binding.
4. Central catalog rows expose object kind MARKET_BARS and schema market-bars/1, while the consumer currently requires object kind PARQUET; the pinned execution policy declares market-bars-v2. The immutable shard embeds schema_version=market-bars/1.

These are frozen-input compatibility/coordination conflicts, not byte corruption. Silently rewriting the plan, catalog version, manifest hash, object kind, or policy would no longer replay the exact run and would weaken the fail-closed boundary.

Needed decision

Decide and document one auditable compatibility strategy for this already-published input set (for example, an explicit legacy adapter with its own validated hash/schema rules), or explicitly declare this old run non-replayable and regenerate a new coherent immutable release input set. Add an exact fixture regression before implementation. Until that decision and regression pass, INT03 remains NOT READY and a Development rerun should not be dispatched.

[hjcud]

Development confirmation after release 31302328826

The one newly authorized INT03 journey confirms #255/#257 are deployed and fixed for new plans:

• run 6c7cc267-ab2a-32a6-846d-e80523a3abc5
• plan sha256:858e44ca29bc8bde1a0a22b9310f18a1e6e56aecb01b1e296ac2ee145d83c930
• fixed cash 100000.00000000
• fixed catalog us-supported-universe:2026-07-31

It then exposed the next frozen-input/runtime conflict predicted by the isolated rehearsal. Attempts 1-5 all ended HANDLER_ERROR:CalendarCoverageError / RETRY_RELEASED before simulation because the policy starts at 2016-07-01 while xnys-2024-2026:1.0.0 starts at 2024-01-01. The run remains QUEUED; worker restart_total=0. No retry journey or operational mutation was performed.

This is additional evidence for #471, not evidence that #255/#257 failed. A coherent fix must be rehearsed against the exact policy/manifest/calendar/schema set locally before another public journey.

[hjcud]

Calendar-window fix is now available as draft PR Idea2Strategy/Idea2Strategy-backtest-engine#85 at commit fc61476.

Verified behavior:

• schedules only the immutable job requirement window, not the policy applicability envelope
• genuine pinned-calendar coverage mismatch becomes one non-retryable REQUIRED_INPUT_UNAVAILABLE attempt
• local: 1,252 non-Docker tests passed; 158 Docker tests passed; Ruff/mypy/pip-audit passed
• GitHub Actions run 31304929297: all 9 gates passed

This removes the newly observed CalendarCoverageError retry loop but does not resolve the separate legacy dataset hash/object-kind/schema incompatibility tracked in this issue. No additional Development INT03 journey should be dispatched until the PR is reviewed/merged/deployed and the remaining compatibility decision is resolved.

[hjcud]

@kcrmin read-only Development inventory sharpens the required producer/policy handoff:

• development-official-backtest-2026-q3-v1 declares an actual 2016-07-01..2026-07-01 evaluation and market-bars-v2.
• Development has annual adjusted 30m market-bars/1 manifests for 2016 through 2026, but no one 10-year composite manifest and no 10-year market-bars-v2 manifest.
• The only market-bars-v2 catalog object is a one-day RAW fixture, so it cannot satisfy the official policy.
• The currently pinned adjusted manifest 7f7113c9-3b02-4098-97ec-0baa07e2b3b0 is coherent for 2024-01-01..2024-02-01 and has an already-verified RSI feature materialization covering that interval.

Recommended proper Development unblock: publish a new immutable execution-policy version for exactly 2024-01-01..2024-02-01 with market-bars/1, update Backend launch-input selection to pin that new version and existing adjusted manifest, retain v1 unchanged/retired, and add a producer compatibility guard proving policy period/schema equals the selected manifest before Run + Outbox commit. Then prepare the root pointer/Flyway bundle and Development release. A ten-year market-bars-v2 policy remains a separate data-publication milestone, not something to fake or silently adapt.

Please confirm/own that policy choice and the root pointer/deployment handoff. Backtest PR #84 is merged and correctly rejects the current incompatible tuple once before RUNNING; my overlapping PR #85 and issue #82 were closed as superseded.

[hjcud]

@kcrmin the backtest-side INT03 fix is now complete and merged.

• merged PR: Consume the immutable INT03 legacy market manifest Idea2Strategy-backtest-engine#87
• exact backtest-engine develop SHA: b8efbc4342d6c89c9bfd7abcf71d546e07e4540b
• GitHub Actions run 31306300353: all 9 gates passed, including PostgreSQL+LocalStack and exact S3 storage checks
• exact legacy Development manifest/hash and S3 VersionId reads are covered by the merged regression

The root-owned handoff is now ready:

1. Point the root backtest-engine gitlink at b8efbc4342d6c89c9bfd7abcf71d546e07e4540b.
2. Publish development-official-backtest-2026-q3-v2 with release quarter 2026-Q3, ET evaluation window 2024-01-01T05:00:00Z through 2024-02-01T05:00:00Z, and schema market-bars/1.
3. Bind manifest 7f7113c9-3b02-4098-97ec-0baa07e2b3b0 / hash 08a848a5f9aa1aac80e215c2d86bcf6d5f96c354400c7c16394dae9ffa9939af; preserve v1 as historical evidence but retire it from the active runtime catalog because one release quarter cannot select two active policies.
4. Add the Backend pre-commit compatibility guard so policy local-date period/schema must match the selected manifest before Run + Outbox commit.
5. Refresh the root Flyway bundle required by the pointer policy and run the Development release workflow.
6. Rotate the Development runtime database credential through the authorized secret-management path as part of the release; do not post the credential value.

Please return the root PR/merge SHA and successful Development release run URL/ID. Do not dispatch another INT03 journey; after deployment evidence is green, this session will use the single authorized journey and preserve all existing runs.

[hjcud]

Implementation note from the current Backend origin/develop (0822bd5) so the handoff does not leave a bypass:

• Guard location: modules/backend-persistence/src/main/java/com/idea2strategy/backend/persistence/strategy/ImmutableStrategyReleaseJooqCommandAdapter.java, inside saveOfficialBacktestOnce, before backtest.runs, input pins, or Outbox inserts.
• The current dataset query reads only hash and dates; it must also read schema_version and data_layer and require this official Basic input to be ADJUSTED.
• The current policy query is only locked_at <= release; it must also reject a policy retired at/before the release instant and read policy_document.periodStart, periodEnd, marketDataSchemaVersion, and timezone.
• For market-bars/1, compare the manifest's legacy UTC date labels to the policy's local-midnight calendar dates (America/New_York), exactly as backtest-engine chore: advance backend through E08 #87 now does. For canonical schemas, retain exact instant equality.
• Require policy schema == manifest schema before any durable write. Add integration tests proving period/schema/data-layer/retired-policy mismatches leave bot.bots, backtest.runs, input pins, and operations.outbox_messages at zero.

StrategyReleaseInputCatalogJooqQueryAdapter currently lists active policies and datasets independently rather than as compatible pairs, so the transactional producer guard is mandatory even if the catalog/UI is also filtered.

[kcrmin]

요청 5단계 완료 — 배포 성공

release run: https://github.com/Idea2Strategy/Idea2Strategy/actions/runs/31308512547
run ID 31308512547 · conclusion success · sha 6eb22a4

bootstrap-database   success
build                success
prepare-and-plan     success
apply-reviewed-plan  success
롤아웃 core/trading/backtest-worker 3건 + 배포 검증 전부 passed

단계	결과
1. backtest-engine 포인터 → b8efbc4	완료
2. 정책 v2 게시	완료 — DB 확인
3. backend producer guard	완료 — backend #266 (81b6d45)
4. Flyway 번들 + 배포	완료 — bundle f79a1a53…
5. run URL·결과	이 코멘트

배포 후 직접 확인한 것

워커   image @sha256:c181a64f3b74ef99681243b105a3effc7c406854371c0dce3275dd96dfe817f0
       status=running restarts=0 started=2026-08-09T11:00:42Z
       BACKTEST_WORKER_CORRELATION_ID=b915ae58-9bfd-5c36-8a36-f28a590403d2 (UUID)

정책   v2  locked 2026-08-09 00:00Z  period 2024-01-01T05:00:00Z ~ 2024-02-01T05:00:00Z  market-bars/1
       v1  locked 2026-07-01 04:00Z  period 2016-07-01Z ~ 2026-07-01Z                    market-bars-v2

v1 은 DB 에서 retire 되지 않았습니다 — 그 이유를 정확히 적습니다

지시는 retire 였지만 원격 부트스트랩이 정책 seed 의 UPDATE 를 거부합니다.
scripts/aws/development-database-bootstrap.sh:202 가 INSERT 외 어떤 명령도, 주석 안의 단어까지
막습니다(exit 65). 발행된 정책 행을 나중 seed 가 다시 쓰지 못하게 하는 append-only 방어이고, 그 방어가
옳으므로 느슨하게 하지 않았습니다. 첫 릴리스 31308070007 이 이것으로 실패했습니다.

그래서 retired_at 은 NULL 입니다. v1 이 도달 불가한 이유는 두 가지입니다.

1. 런타임 카탈로그 파일이 v2 만 싣습니다 — 워커가 로드하는 것이 이 파일이고
   ExecutionPolicyCatalog 는 같은 releaseQuarter 의 두 정책을 거부합니다.
2. producer guard 가 v1 을 거부합니다 — 10년 창과 market-bars-v2 가 모든 AVAILABLE manifest 와
   불일치하므로, durable 쓰기 이전에 막힙니다.

artifact-manifest.json 의 amendment.supersededHandling 에 같은 내용이 기록돼 있습니다. 일어나지 않은
retirement 를 일어난 것처럼 적지 않았습니다.

정책 문서에 datasetManifestId·datasetHash 를 넣지 않은 이유

소비자 ExecutionPolicy 가 두 필드를 모델링하지 않아 문서에 넣어도 계약이 되지 않습니다. 두 값은
amendment.verifiedManifest 에 검증 근거로 기록하고, 실효는 producer guard 가 담당합니다 — 요청의
manifest 가 정책의 기간·스키마와 호환되고 ADJUSTED 일 때만 통과합니다.

periodStart/End 를 05:00Z 로 둔 것도 확인했습니다 — ExecutionPolicy.__post_init__ 이 정책 시간대의
지역 자정을 요구하고 1월(EST)에 그것이 05:00Z 입니다. releaseQuarter 는 2026-Q3 유지입니다(카탈로그가
데이터 창이 아니라 출시 분기로 선택).

신규 여정 1회 진행 가능합니다

기존 run 4건(c0df2755·dcc110d7·66956d2d·9d4a31d5)은 전부 보존했고, 재실행·DLQ 조작·DB 직접
수정·워커 조작은 하지 않았습니다.

출시 시 executionPolicyVersion 은 development-official-backtest-2026-q3-v2, 데이터셋은
7f7113c9-3b02-4098-97ec-0baa07e2b3b0 (ADJUSTED 30m 2024-01) 입니다. 다른 조합은 guard 가 durable
쓰기 이전에 거부하므로, 이제 불일치가 run 으로 남지 않고 요청 단계에서 막힙니다.