feat: rename forge.proto → core.proto + dual-listen on /forge.Forge and /core.Core

[shayan1995]

feat: rename forge.proto → core.proto + dual-listen on /forge.Forge and /core.Core

Description

Smallest possible step toward NICo, per review feedback:

1. Rename crates/rpc/proto/forge.proto → crates/rpc/proto/core.proto
2. Inside core.proto: package forge; → package core;
3. Inside core.proto: service Forge { → service Core {
4. In crates/api/src/listener.rs, register an additional alias route so the server accepts both /forge.Forge/* and /core.Core/* wire paths. The alias rewrites /forge.Forge/<method> → /core.Core/<method> before dispatch; payload bytes are untouched.

No message types, field names, enum values, or comments are renamed in this PR. All those breaking attribute renames are deferred to a smaller follow-up PR so reviewers can evaluate them independently.

Also flips vault.nicoApiK8sAuth.enabled: false → true in helm-prereqs/values.yaml — fixes a tight-loop "invalid role name" error in fresh setup.sh deploys (separate commit on this branch, unrelated to the proto rename).

Files changed

File	Change
crates/rpc/proto/{forge.proto → core.proto}	git-detected rename, content delta = 2 lines (package + service)
crates/rpc/build.rs	Update proto file path, reflection bin name, and ~250 type_attribute prefixes from forge.X to core.X
crates/rpc/src/protos/mod.rs	Declare pub mod core; (the renamed generated module). Add a backward-compat alias pub mod forge { pub use super::core::*; ... } so existing crate::protos::forge::* callsites in the workspace keep compiling unchanged
crates/api/src/listener.rs	Add the alias route for /forge.Forge/* with a tower::ServiceBuilder::map_request path-rewrite to /core.Core/*
helm-prereqs/values.yaml	vault.nicoApiK8sAuth.enabled: false → true (separate commit)

Type of Change

• Add - New feature or capability (new /core.Core/* wire path, generated core::* Rust module)
• Change - Changes in existing functionality (chart default nicoApiK8sAuth.enabled)
• Fix - Bug fixes
• Remove - Removed features or deprecated functionality
• Internal - Internal changes (refactoring, tests, docs, etc.)

Related Issues (Optional)

Follow-up PRs in the rename rollout:

• Rename Forge* message types to Core* (ForgeAgentControl → CoreAgentControl, etc.)
• Rename forge_* field names to core_* (forge_dpu_agent → core_dpu_agent, etc.)
• Migrate crate::protos::forge::* Rust callsites to crate::protos::core::* and drop the backward-compat alias module

Breaking Changes

• This PR contains breaking changes

Wire-level: /forge.Forge/* continues to work through the alias route. Existing clients (site-agent, admin-cli, anything not yet rebuilt) are unaffected.

Source-level: crate::protos::forge::* continues to resolve through the alias module in mod.rs. No existing Rust callsite needs to change.

Testing

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed
• No testing required (docs, internal refactor, etc.)

Manual validation:

1. protoc compile of core.proto: clean (only pre-existing unused-import warnings inherited from upstream forge.proto).
2. cargo check -p carbide-rpc -p carbide-tls -p carbide-api-db -p carbide-api-model -p carbide-rpc-utils -p carbide-measured-boot -p carbide-secrets: clean — the alias module in mod.rs keeps the downstream crate::protos::forge::* consumers compiling without modification.
3. helm lint helm-prereqs/: clean.

[shayan1995]

/ok to test 533e60d

[shayan1995]

/ok to test 54e9462

[ajf]

💥

[ajf]

The AI summary doesn't really match the PR. Example,

crates/ssh-console-mock-api-server/build.rs repointed at core.proto.

I don't see this code being changed in the PR.

Anyway, this basically creates a parallel gRPC service named core instead of Forge, cool. I assume site-agent and the old admin-cli needs to get recompiled with the new protos which will happen after this lands? I don't see in this PR where the proto maps to a rust Impl for it, but maybe I missed it.

And while this is happening, we have to update both old and new proto services. Is there no simpler way to have an "alias" for a service or something?

[shayan1995]

Thanks @ajf good catches on both fronts.

On the AI summary being off: you're right, the description didn't match the actual PR. The mock-api-server change and the cross-reference proto edits were in an earlier revision and got reverted (they broke compilation and had inaccurate comments). The PR is actually just four files now: crates/rpc/proto/core.proto (new), crates/rpc/build.rs (compile both protos), crates/rpc/src/protos/mod.rs (one NOTE comment), and helm-prereqs/values.yaml (one default flip). No breaking changes. I'm updating the description.

On client recompile: in-tree admin-cli gets updated by feat/rename-code, which is the follow-up branch. Out-of-tree clients (site-agent in infra-controller-rest) don't need to do anything forge.proto in this PR is byte-identical to main, so /forge.Forge/* keeps working as-is. They migrate to /core.Core/* only when their own repo is ready.

On the Rust impl: intentionally not here. core.rs is generated but pub mod core; is deliberately not declared (there's a // NOTE: in mod.rs explaining). The trait impl + the pub mod core; exposure + updating downstream consumers all land in feat/rename-code — that's a much larger semantic diff and worth its own review.

On the alias question: and yes, you're right that maintaining both is a footgun. I did try the cleaner design: rewrite forge.proto as a thin wrapper that imports core.proto and reuses core.X message types under service Forge. About 933 lines instead of 8300, no schema duplication. protoc compiles it fine and wire compatibility holds (/forge.Forge/* paths still work because the bytes on the wire don't care about the package name of the type so only field numbers, which are unchanged).

what we need to be worried about(catch) : it breaks ~4000 Rust references in this repo that import crate::protos::forge::SomeMessage directly — they'd need to migrate to crate::protos::core::* at the same time, which is exactly what feat/rename-code does. Combining the two into one PR makes for a ~20k-line review. So the plan is to land this small PR first, then do the wrapper conversion either inside feat/rename-code or right after, once Rust callers are migrated. After that the duplication is gone — new RPCs only get added to core.proto, and service Forge picks them up via its rpc signatures.

[thossain-nv]

@ajf I went over the code with @shayan1995 and I think the best course of action would be to:

• Rename forge.proto to core.proto
• Rename forge package to core in core.proto
• Rename Forge service to Core in core.proto
• Add an additional alias listener in https://github.com/NVIDIA/infra-controller/blob/main/crates/api/src/listener.rs#L248 so we can listen to both /forge.Forge/* and /core.Core/* gRPC calls

No breaking attribute renaming will take place in this PR, we can generate another smaller PR for that.