feat: add code agent provider profiles
This commit is contained in:
Codex
@@ -3,75 +3,56 @@
|
||||
This reference defines the stable DEV environment, port, k3s, and runtime
|
||||
substitution rules.
|
||||
|
||||
## Public DEV Ports
|
||||
## Public G14 Runtime Ports
|
||||
|
||||
| Surface | URL |
|
||||
| --- | --- |
|
||||
| Cloud Web browser entry | `http://74.48.78.17:16666/` |
|
||||
| API/edge entry | `http://74.48.78.17:16667/` |
|
||||
| API/live health | `http://74.48.78.17:16667/health/live` |
|
||||
| Surface | DEV URL | PROD URL |
|
||||
| --- | --- | --- |
|
||||
| Cloud Web browser entry | `http://74.48.78.17:17666/` | `http://74.48.78.17:18666/` |
|
||||
| API/edge entry | `http://74.48.78.17:17667/` | `http://74.48.78.17:18667/` |
|
||||
| API/live health | `http://74.48.78.17:17667/health/live` | `http://74.48.78.17:18667/health/live` |
|
||||
|
||||
Public `:6666` and `:6667` are deprecated as browser/API acceptance targets.
|
||||
Internal k3s services may still listen on `6667`; do not rewrite that as a
|
||||
public endpoint.
|
||||
Public `:16666` and `:16667` are D601 legacy DEV endpoints. They can be used only for migration comparison or incident replay, not as the current HWLAB runtime acceptance target. Internal k3s services may still listen on `6667`; do not rewrite that as a public endpoint.
|
||||
|
||||
## Route Shape
|
||||
|
||||
The public route is:
|
||||
The current G14 DEV route is:
|
||||
|
||||
```text
|
||||
master hwlab-frps-dev :16666/:16667
|
||||
-> D601 hwlab-frpc in namespace hwlab-dev
|
||||
master hwlab-frps-dev :17666/:17667
|
||||
-> G14 hwlab-g14-frpc in namespace hwlab-dev
|
||||
-> hwlab-cloud-web on internal :8080 for browser traffic
|
||||
-> hwlab-edge-proxy / hwlab-cloud-api on internal :6667 for API and health
|
||||
```
|
||||
|
||||
`deploy/deploy.json` is the source for public endpoint and FRP mapping drift
|
||||
checks. Use:
|
||||
G14 PROD is rendered by GitOps as namespace `hwlab-prod` and Argo CD application `hwlab-g14-prod`; it uses the `:18666/:18667` public endpoints when enabled. G14 desired state is generated into `deploy/gitops/g14/runtime-dev` and `deploy/gitops/g14/runtime-prod` and promoted through the `G14-gitops` branch.
|
||||
|
||||
## G14 k3s Source Of Truth
|
||||
|
||||
G14 native k3s is the HWLAB DEV/PROD runtime source of truth. Commands that observe or mutate current HWLAB runtime must go through UniDesk route `G14:k3s`, for example:
|
||||
|
||||
```sh
|
||||
node scripts/deploy-contract-plan.mjs --check
|
||||
tran G14:k3s kubectl -n hwlab-dev get deploy,svc,pod -o wide
|
||||
tran G14:k3s kubectl -n argocd get application hwlab-g14-dev hwlab-g14-prod
|
||||
```
|
||||
|
||||
## D601 k3s Source Of Truth
|
||||
Do not use D601 kubeconfig, D601 `dev-cd-apply`, old JS `ci-publish`, Docker Desktop Kubernetes, or master-server local checks as G14 runtime acceptance evidence. D601 remains a legacy migration/reference surface until the branch-role migration is complete.
|
||||
|
||||
D601 native k3s is the DEV runtime source of truth. Commands that observe or
|
||||
roll a DEV workload must specify:
|
||||
## Branch Role Migration
|
||||
|
||||
The target branch model is: G14 becomes the `main` runtime source branch, and the former D601-oriented `main` behavior moves to a D601 legacy/maintenance line. Until that branch governance operation is explicitly completed and verified, `/root/hwlab` on G14 continues to use the `G14` branch and must merge the latest `origin/main` business updates before G14-specific runtime work.
|
||||
|
||||
## Distributed Passthrough Hygiene
|
||||
|
||||
When running more than one command on G14, keep all commands inside one remote `script` block:
|
||||
|
||||
```sh
|
||||
KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl -n hwlab-dev get deploy,svc,pod -o wide
|
||||
tran G14:/root/hwlab script <<'SCRIPT'
|
||||
sed -n '1,80p' docs/reference/dev-runtime-boundary.md
|
||||
sed -n '1,80p' AGENTS.md
|
||||
SCRIPT
|
||||
```
|
||||
|
||||
Do not trust the default `kubectl` context as a DEV runtime signal. On D601 it
|
||||
may point at another cluster such as `docker-desktop`. The 2026-05-23 control
|
||||
plane incident is tracked in
|
||||
[pikasTech/unidesk#138](https://github.com/pikasTech/unidesk/issues/138), with
|
||||
hotfix context in
|
||||
[pikasTech/unidesk#118](https://github.com/pikasTech/unidesk/issues/118):
|
||||
Docker Desktop Kubernetes has been disabled and cleaned, but the default
|
||||
`/home/ubuntu/.kube/config` may still point at the dead
|
||||
`docker-desktop`/`127.0.0.1:11700` entry. Treat that as residual bad config, not
|
||||
as DEV runtime evidence.
|
||||
|
||||
Before any DEV deploy, rollback, smoke, or manual k3s observation, confirm the
|
||||
native node explicitly:
|
||||
|
||||
```sh
|
||||
KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get nodes -o jsonpath='{.items[*].metadata.name}'
|
||||
```
|
||||
|
||||
The result must contain `d601`. Seeing `desktop-control-plane`,
|
||||
`docker-desktop`, or `127.0.0.1:11700` means the command is on the wrong
|
||||
control-plane path and must stop before mutation or acceptance.
|
||||
|
||||
Use the read-only preflight when a runner needs to report k3s visibility:
|
||||
|
||||
```sh
|
||||
node scripts/d601-k3s-readonly-observability.mjs
|
||||
```
|
||||
|
||||
The preflight must not print secret values, kubeconfig material, ConfigMap
|
||||
values, or token content.
|
||||
Do not write `tran G14:/root/hwlab sed ... && sed ...` unless the second command is intentionally local. Shell operators such as `&&`, `;`, and pipes outside the `tran` invocation are evaluated by the local shell; this can make later commands run on the master server and look like a missing-file or truncation bug.
|
||||
|
||||
## Cloud API DB Readiness Authority
|
||||
|
||||
|
||||
Reference in New Issue
Block a user