Requirements 확인 질문

requirements/enode-features.md §5 는 미정이 없다고 적었고, 그것이 맞다.
아래는 새 미정이 아니라 그 문서가 예고한 것이다 — 「게이트에서 새 미정이
생기면 그것은 계약(서명 · 파일 · 응답 모양)에 걸리는 것이어야 하고,
진행자가 decisions.md 에 행을 더한다」(§5).

셋뿐이다. 셋 다 응답 모양이나 함수 계약에 걸리고, decisions.md 가
값을 주지 않았다. 값이 정해지면 decisions.md 2절에 행으로 올린다.

권장안을 A 에 두었다. 그대로면 A 만 적으면 된다.

Question 1

QUEUED 인 Run 의 steps 행을 언제 만드는가. GET /v1/runs/{id} 가
대기 중인 Run 에 대해 무엇을 내는지가 여기서 갈린다.

지금 코드는 CreateRun 이 한 트랜잭션에서 Run · 임대 · 단계를 만들고,
이어서 runAcquires 와 raiseAsks 를 돈다. QUEUED 는 임대를 안 쥐므로
그 셋을 어떻게 가르는지가 정해져야 한다.

A) 제출 시점에 만든다. steps 를 전부 PENDING 으로 넣고 node_id 는
비운다. runAcquires 와 raiseAsks 는 승격 시점으로 미룬다. 승격은
매칭 · 임대 발급 · steps.node_id 채우기 · 획득 · 되묻기만 한다.
이러면 계약의 구조 검증(st.Kind() · contract.NeedsOf)이 제출에 동기로
붙어 202 를 받은 뒤에 구조 오류로 조용히 죽는 일이 없고, S2 작업 그래프가
대기 중에도 그려진다

B) 승격 시점에 만든다. QUEUED 인 Run 은 steps 가 비어 있다.
api.go 의 view 주석이 「배정 전(ALLOCATING)이면 단계가 없는 것이
정상」이라고 적은 것과 같은 자리로 둔다. 대신 계약의 구조 오류는 승격
시점에야 드러나고, 그때는 보고할 호출자가 없다

X) Other (please describe after Answer: tag below)

Question 2

store.WakeQueued(ctx) error 가 한 번 불릴 때 보는 범위는 어디까지인가.
unit-boundaries.md §4 가 서명과 「재진입 · 동시 호출 안전」은 정했으나
범위는 안 정했다. 이 함수를 U-대기열 · U-drain · 기동이 함께 부른다.

A) created_at 오름차순으로 QUEUED 를 전부 훑고, 지금 매칭되는 것을
전부 승격한다. 도착 순서가 곧 시도 순서다 — 같은 자원을 다투는 것들
사이에서는 FIFO 가 그대로 산다. 앞의 Run 이 못 가도 뒤를 막지 않는다

B) 머리 하나만 본다. 가장 오래된 QUEUED 가 못 가면 거기서 멈춘다.
엄격한 한 줄 대기열이다. 대신 보드를 기다리는 Run 이 머리에 있으면
전혀 다른 능력을 기다리는 뒤의 Run 이 자원이 비어 있어도 못 간다
(head-of-line blocking)

X) Other (please describe after Answer: tag below)

Question 3

security-baseline 의 SECURITY-04 (HTTP 보안 헤더) 를 이번에 생기는
HTML 표면 둘 — 중앙 현황판 GET /ui/ 와 호스트 제어판 / — 에 어떻게
거는가. decisions.md 3절이 SECURITY-01 · 03 · 07 · 08 · 12 의 취급은
적었으나 04 는 안 적었고, 확장 규칙은 기본이 차단성이다. 그래서
정하지 않으면 단계마다 blocking 이 뜬다.

constraints.md §6 이 HTTPS · TLS 를 범위 밖으로 뒀다는 것이 이 질문의 배경이다.

A) 네 헤더를 걸고 HSTS 는 N/A 로 근거를 적는다.
Content-Security-Policy: default-src 'self' · X-Content-Type-Options: nosniff ·
X-Frame-Options: DENY · Referrer-Policy: strict-origin-when-cross-origin 을
두 표면에 건다. Strict-Transport-Security 는 평문 HTTP 에서 뜻이 없고 TLS 가
constraints.md §6 이므로 N/A 로 기록한다. CSP 에 unsafe-inline 을 안 쓰므로
화면의 JS 와 CSS 는 인라인이 아니라 별도 파일이어야 한다 — 이것이 U-화면의
파일 구성을 정한다

B) 다섯을 전부 건다. HSTS 도 보낸다. 평문 HTTP 라 브라우저가 무시하지만
규칙 문면을 그대로 지킨다

C) 안 건다. decisions.md 3절 목록에 없으므로 기존 코드와 같은 취급으로
보고 사실만 기록한다

X) Other (please describe after Answer: tag below)

확장 opt-in — 이미 답이 있다

규칙이 Requirements Analysis 에서 확장 opt-in 프롬프트를 물으라고 한다.
aidlc-docs/aidlc-state.md 의 ## Extension Configuration 에 사용자 결정
2026-09-04 로 답이 이미 있으므로 그 값을 적어 두었다. 바꿀 것이 있을 때만
고치면 된다.

Question: Security Extensions

Should security extension rules be enforced for this project?

A) Yes — enforce all SECURITY rules as blocking constraints

B) No — skip all SECURITY rules

X) Other (please describe after Answer: tag below)

Question: Resiliency Extensions

Should the resiliency baseline be applied to this project?

A) Yes — apply the resiliency baseline as directional best practices

B) No — skip the resiliency baseline

X) Other (please describe after Answer: tag below)

Question: Property-Based Testing Extension

Should property-based testing (PBT) rules be enforced for this project?

A) Yes — enforce all PBT rules as blocking constraints

B) Partial — enforce PBT rules only for pure functions and serialization round-trips

C) No — skip all PBT rules

X) Other (please describe after Answer: tag below)