화면 대조 확인 질문 — 두 번째 묶음

design/exports/ 의 화면 다섯을 열고 나온 것이다. 셋뿐이고 셋 다 응답
모양이거나 라우트 집합이다. decisions.md 도 ADR-065 도 답을 갖고 있지
않다. 나머지 여덟 자리는 근거를 적고 닫았다 — requirements.md §8.2.

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

Question 1

S1 카드의 **「지금 무슨 단계 · 회차 · 시작 시각」**과 Run 목록 행의 부제는
어디서 오는가.

그림이 요구하는 것:

   S1 카드     build.kernel · 회차 2 · 12:58:03 시작        (임대된 카드마다)
   Run 행      ws-a · build.kernel · 12:58:03               (RUNNING)
               노드 미배정 · 12:59:19 접수                   (QUEUED)
               ws-b · 11:20:55 완료                          (SUCCEEDED)
               함대에 능력 없음 · 10:58:02                     (FAILED — 거절 사유)

GET /v1/nodes 의 lease{run_id, not_after} 에도, decisions.md 2절이 정한
GET /v1/runs 의 {run_id, state, verdict, work_id, created_at, ended_at, assigned} 에도 단계 이름과 거절 사유가 없다. 그런데
enode-features.md 3.1.1 은 카드가 「지금 무슨 단계」를 보여야 한다고 적었다.

A) GET /v1/runs 행에 둘을 더한다. current{step, attempt, started_at}
(도는 단계가 없으면 null)과 reject{code, as, reason}. S1 은 이미 같은
화면에서 GET /v1/runs 를 부르므로 카드는 lease.run_id 로 조인만 하면
된다. 폴링당 요청이 둘로 유지되고 ADR-065 의 lease 는 draining 말고는
안 건드린다. GET /v1/runs 는 이 팩이 새로 만드는 것이라 개정 부담도 없다

B) GET /v1/nodes 의 lease 를 넓힌다. lease{run_id, not_after, step, attempt, started_at}. 카드가 조인 없이 찬다. 대신 ADR-065 개정 범위가
draining 하나에서 lease 세 필드까지 늘고, Run 행의 거절 사유는 여전히
따로 필요하다

C) 화면이 임대된 노드마다 GET /v1/runs/{id} 를 더 부른다. 응답 모양을
안 바꾼다. 대신 5초마다 요청이 1 + 임대 수 가 된다 (그림의 예에서 넷).
decisions.md 2절이 제어판(노드 하나) 에 정한 방식을 현황판(노드 전부)에
그대로 늘린 것이다

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

Question 2

enodectl serve 는 이 기계의 노드 몇 개를 서브하는가.

S3 · S5 의 왼쪽에 「이 기계의 노드」 사이드바가 있고 항목이 둘이다
(ws-a · ws-b / board-01 · board-02). 고르면 오른쪽이 바뀌는 모양이다.
그런데 enode-features.md 3.1.2 는 「이름은 기존 하위 명령과 같은 규칙 —
names() 가 하나면 생략, 여럿이면 필수」라고 적었다. 여럿이면 필수라는 것은
하나만 서브한다는 뜻이다.

A) 전부 서브한다. enodectl serve [name] 에서 이름은 처음 선택될 노드
일 뿐이고 여럿이어도 생략할 수 있다 (생략하면 names() 의 첫째). 라우트가
노드를 받는다 — GET /api/status?node=<name> · PUT /api/policy?node=<name>
등. 근거는 사이드바가 「멈춘 노드는 이 화면에만 나온다」를 말하는 자리라는
것이다. 기계에 노드가 둘인데 둘을 보려고 포트 둘에 serve 를 띄우는 것은
소유자 화면으로 이상하다

B) 하나만 서브한다. enodectl serve <name> 은 여럿이면 이름 필수 —
요구사항 문면 그대로다. 사이드바는 「이 기계에 이런 것도 있다」를 보이기만
하고 못 고른다. 다른 노드를 보려면 다른 포트로 serve 를 또 띄운다.
라우트에 노드 인자가 없어 표면이 얇다

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

Question 3

멈춘 노드의 **「마지막 관측」**은 어디서 오는가.

S5 가 seen_at 12:57:11 · expires_at 13:00:11 · lease 없음 ·
instance 마지막 7d8f4c02 를 보인다. 이 값들의 출처는 Mediator 의
GET /v1/nodes 인데, 그 라우트는 만료되지 않은 광고만 낸다
(ADR-065 · enode-features.md 3.1.1). 데몬이 멎고 광고가 만료되면 행이
사라져 제어판이 읽을 데가 없어진다. 그림의 예도 만료 전(13:00:11)의 한 순간을
그린 것이다.

unit-boundaries.md 는 「겉면은 얇게 — Config · Server · New」라고
적었다. 캐시를 들면 제어판이 상태를 갖는다.

A) 제어판이 메모리에 마지막 성공 관측을 든다. serve 가 도는 동안만
살고 재시작하면 빈다. 비었으면 화면이 — 로 그린다. /api/status 가
observed{seen_at, expires_at, lease, instance, at} 과 stale: true|false
를 낸다. 근거는 FR-23(「Mediator 마지막 응답 시각」)이 이미 같은 성질의
메모리 상태를 요구한다는 것 — 부품이 하나 느는 것이 아니라 같은 부품이다.
디스크에 안 쓰므로 정본이 갈리지 않는다

B) 안 든다. 광고가 만료되면 「마지막 관측」 칸이 비고 화면이 「중앙이
이 노드를 잊었다」로 적는다. 제어판은 완전히 무상태로 남는다. 대신 S5 가
그림대로 안 그려지는 순간이 생긴다 — 데몬을 멈추고 3분이 지나면 값이 사라진다

C) 데몬이 마지막 광고를 로컬 파일에 남긴다. 만료와 무관하게 읽을 수
있다. 대신 internal/enode 에 새 상태 파일이 생긴다 — decisions.md 2절이
「데몬이 상태 파일을 남기는 것은 새 기계다」로 이미 기각한 자리다

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