docs(stovepipe): rename project status lookup

Author: mnoah1

doc/rfc/index.md

@@ -29,7 +29,7 @@ Design documents and technical proposals, grouped by scope. Shared/cross-cutting
 - [Build stage](stovepipe/steps/build.md) - Trigger-only stage and Stovepipe's URI-based BuildRunner contract
 - [Buildsignal stage](stovepipe/steps/buildsignal.md) - Build polling, terminal status persistence, and the handoff to record
 - [Record stage](stovepipe/steps/record.md) - Immutable validation facts keyed by `(queue, uri, project)`, monotonic last-green bookmark advancement and ref promotion, and the deferred hook-event and analyze handoffs
-- [GetValidation API](stovepipe/get-validation-api.md) - Current request lifecycle, whole-repository result, and cursor-paginated project validation results backed by one durable project manifest
+- [GetProjectStatusByURI API](stovepipe/get-validation-api.md) - Current request lifecycle, whole-repository result, and cursor-paginated project validation results backed by one durable project manifest
 
 ## Runway
 

doc/rfc/stovepipe/get-validation-api.md

@@ -1,19 +1,19 @@
-# Stovepipe GetValidation API
+# Stovepipe GetProjectStatusByURI API
 
 ## Summary
 
-Stovepipe exposes the current validation of one queue and commit through `GetValidation`. The response combines request lifecycle, the whole-repository result, and the request's complete planned project list with any results recorded for those projects.
+Stovepipe exposes the current validation of one queue and commit through `GetProjectStatusByURI`. The response combines request lifecycle, the whole-repository result, and the request's complete planned project list with any results recorded for those projects.
 
 This is a current-state API, not another history projection. It reads `Request` for lifecycle and scope, `ValidationFact` for immutable results, and a request-owned project manifest for enumeration and completion. The manifest is also the single project list used by validation planning and downstream consumers.
 
-The contract is based on the `GetValidation` flow in [Stovepipe <-> CD Integration: Event and API Contract](https://docs.google.com/document/d/1ouymU93l2a6lLiKwhqViSR1HFdwviuywj_sL6gDNeQM/edit?tab=t.n2tdz7ihz0sk).
+The contract is based on the validation lookup flow in [Stovepipe <-> CD Integration: Event and API Contract](https://docs.google.com/document/d/1ouymU93l2a6lLiKwhqViSR1HFdwviuywj_sL6gDNeQM/edit?tab=t.n2tdz7ihz0sk).
 
 ## Representative Contract
 
 The final protobuf receives a separate compatibility review before implementation. Its representative shape is:
 
 ```proto
-message GetValidationRequest {
+message GetProjectStatusByURIRequest {
     string queue = 1;
     string change_uri = 2;
     optional string project = 3;
@@ -30,7 +30,7 @@ message ProjectValidation {
     ValidationResult result = 2;
 }
 
-message GetValidationResponse {
+message GetProjectStatusByURIResponse {
     string request_id = 1;
     string queue = 2;
     string change_uri = 3;
@@ -43,7 +43,7 @@ message GetValidationResponse {
 }
 
 service Stovepipe {
-    rpc GetValidation(GetValidationRequest) returns (GetValidationResponse) {}
+    rpc GetProjectStatusByURI(GetProjectStatusByURIRequest) returns (GetProjectStatusByURIResponse) {}
 }
 ```
 
@@ -57,9 +57,9 @@ The existing degree scale answers “how broken is this scope”: `0.0` is fully
 
 The controller verifies that the loaded Request has the requested queue and URI before loading its project manifest and whole-repository fact. Request URI is immutable once the request and mapping are created; storage updates must not permit the two records to diverge.
 
-Ingest claims `request_uri` before creating the Request so concurrent ingests converge without a cross-record transaction. A lookup racing that sequence can therefore observe a mapping whose Request is not present yet. `GetValidation` treats that condition as unavailable and retryable rather than not found or immediate corruption. Repeated occurrences are surfaced through consistency metrics and require repair; a mapping to a Request with a different queue or URI is an internal consistency error.
+Ingest claims `request_uri` before creating the Request so concurrent ingests converge without a cross-record transaction. A lookup racing that sequence can therefore observe a mapping whose Request is not present yet. `GetProjectStatusByURI` treats that condition as unavailable and retryable rather than not found or immediate corruption. Repeated occurrences are surfaced through consistency metrics and require repair; a mapping to a Request with a different queue or URI is an internal consistency error.
 
-`request_state` uses the same stable public vocabulary as [Stovepipe Request History](request-history-api.md): `accepted`, `processing`, `succeeded`, `failed`, `cancelled`, and `superseded`. One value identifies both lifecycle position and terminal outcome without permitting contradictory field combinations. The wire field is a string, following SubmitQueue's current-status and history APIs, so clients can tolerate additive vocabulary changes. It is projected explicitly from Stovepipe's internal `RequestState`; no SubmitQueue domain enum is shared across the boundary.
+`request_state` uses the stable public vocabulary `accepted`, `processing`, `succeeded`, `failed`, `cancelled`, and `superseded`. One value identifies both lifecycle position and terminal outcome without permitting contradictory field combinations. The wire field is a string, following SubmitQueue's current-status and history APIs, so clients can tolerate additive vocabulary changes. It is projected explicitly from Stovepipe's internal `RequestState`; no SubmitQueue domain enum is shared across the boundary.
 
 `failed` retains the current conservative meaning: either validation failed or the request could not continue. The API does not synthesize a `COMPLETED` versus `ERROR` distinction that the Request does not persist. Adding that distinction later requires a durable outcome classification first, followed by an additive response field.
 
@@ -81,7 +81,7 @@ Request terminal state and result completion are intentionally distinct. The cur
 
 ## Pagination and Consistency
 
-Pagination follows the same public convention as Stovepipe request history and SubmitQueue queue listing: an empty token selects the first page, zero page size selects the server default, and `next_page_token` is empty on the final page. The initial default is 50 projects and the maximum is 200.
+Pagination follows SubmitQueue's queue-listing convention: an empty token selects the first page, zero page size selects the server default, and `next_page_token` is empty on the final page. The initial default is 50 projects and the maximum is 200.
 
 The controller reads the immutable manifest in `project ASC` order and inspects one project beyond the effective page size before issuing a continuation token. The opaque, versioned token represents the exclusive position after the last returned project and is bound to the queue, change URI, resolved request ID, and all-project selector mode. Decoding produces a typed manifest cursor; neither the manifest store nor the fact store parses public tokens. The cursor may include a deterministic chunk position in addition to the last project ID without exposing either representation to clients. Page size is not bound, so callers may change it between pages. A malformed token, unsupported version, or token reused for another query is invalid.