mirror of
https://github.com/getpaseo/paseo.git
synced 2026-07-29 12:01:31 +00:00
a8ebd390fa
* refactor(forge): forge-neutral foundation (GitHub-only) Decouple git-hosting from GitHub behind a neutral abstraction (issue #1616), GitHub-only for now; existing GitHub behaviour is unchanged. - Forge manifest, neutral ForgeService contract, forge registry + resolver, and a client forge-module registry. - GitHub code renamed to the neutral shape; PR/Issue attachment wording preserved. - forge.search.response enums parse tolerantly (unknown kind/auth state degrade instead of breaking the client). - createPullRequest reports typed CLI/auth errors instead of a generic message. - forge-resolver host/remote caches are LRU-bounded. - Forge host trust is explicit: only a known cloud host or a CLI-authenticated host is ever talked to; an unauthenticated GitHub Enterprise host fails resolution instead of routing to github.com. - Docs: forge-providers guide, glossary and i18n forge-copy conventions, architecture and rpc-namespacing terminology. - Vitest React Native mocks (unistyles, svg, linking, lucide) consolidated into shared aliased test-stubs. * feat(forge): GitLab adapter, forge-aware UI, pipelines and approvals GitLab adapter over the glab CLI on the neutral contracts: MR status, forge-aware UI, pipeline tree, and N-of-M approvals. - threadIsResolved is part of the neutral timeline item. - Pipeline load failures show an error instead of an empty section. - Manual pipeline jobs render as pending. - Fork/detached MR head pipelines are fetched by MR iid (glab ci get --merge-request). * feat(forge): Gitea family adapter (Gitea, Forgejo, Codeberg) One adapter over the tea CLI serving Gitea, Forgejo, and Codeberg on the neutral contracts. - CI status aggregates commit statuses and Actions runs together. - Gitea's terminal "warning" state maps to failure on server and client. - Gitea Actions check details are reachable from the PR pane by workflowRunId. * refactor(forge): localize compatibility handling * test(forge): expect normalized GitLab facts --------- Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>
87 lines
2.6 KiB
Markdown
87 lines
2.6 KiB
Markdown
# RPC Namespacing
|
|
|
|
New WebSocket session RPCs use dotted names with the direction as the final segment:
|
|
|
|
```ts
|
|
checkout.forge.set_auto_merge.request;
|
|
checkout.forge.set_auto_merge.response;
|
|
```
|
|
|
|
The namespace reads left to right:
|
|
|
|
- Domain: `checkout`
|
|
- Namespace segment: `forge`
|
|
- Operation: `set_auto_merge`; this segment is a verb, not a noun. If you would name an RPC `noun.request`, name it `get_noun.request` instead.
|
|
- Direction: `request` or `response`
|
|
|
|
Use dots, not slashes. Dots are protocol namespaces; slashes imply paths or transport routing.
|
|
|
|
## Request/Response Pairs
|
|
|
|
For ordinary correlated RPCs, a `.request` has a matching `.response` with the same prefix. The daemon client may derive the response type mechanically:
|
|
|
|
```ts
|
|
checkout.forge.set_auto_merge.request;
|
|
// -> checkout.forge.set_auto_merge.response
|
|
```
|
|
|
|
Most new RPCs should follow this shape. If a request does not have a one-to-one response, call that out in the code near the schema.
|
|
|
|
## Message Shape
|
|
|
|
Requests keep their parameters at the top level:
|
|
|
|
```ts
|
|
{
|
|
type: "checkout.forge.set_auto_merge.request",
|
|
cwd: "/repo",
|
|
enabled: true,
|
|
mergeMethod: "squash",
|
|
requestId: "req_123"
|
|
}
|
|
```
|
|
|
|
Responses put correlated result data under `payload`:
|
|
|
|
```ts
|
|
{
|
|
type: "checkout.forge.set_auto_merge.response",
|
|
payload: {
|
|
cwd: "/repo",
|
|
enabled: true,
|
|
success: true,
|
|
error: null,
|
|
requestId: "req_123"
|
|
}
|
|
}
|
|
```
|
|
|
|
Keep `requestId` in both request and response payloads. It is the correlation key.
|
|
|
|
## Forge Namespacing
|
|
|
|
Forge-neutral behavior currently uses `checkout.forge.*` for checkout-scoped operations and `forge.search.*` for forge search; forge-specific names belong here only after schema and session handlers exist:
|
|
|
|
- `checkout.forge.*` for operations whose request/response shape is genuinely
|
|
forge-neutral and whose implementation dispatches through the forge resolver.
|
|
- `checkout.github.*` for existing GitHub-specific compatibility RPCs while
|
|
callers migrate to the neutral `checkout.forge.*` shape
|
|
|
|
Do not put GitHub-specific enums or semantics into `checkout.forge.*` RPC names. A generic forge RPC should only exist when the behavior is genuinely forge-neutral.
|
|
|
|
## Compatibility
|
|
|
|
The existing flat RPC names remain part of the protocol until they are intentionally migrated:
|
|
|
|
```ts
|
|
checkout_pr_merge_request;
|
|
checkout_pr_merge_response;
|
|
```
|
|
|
|
Do not add new flat names. When migrating old RPCs, keep protocol compatibility rules in mind:
|
|
|
|
- Add the new names first.
|
|
- Gate new feature behavior through `server_info.features.*` when an old host cannot support it.
|
|
- Keep old names accepted until the compatibility window expires.
|
|
- Mark shims with `COMPAT(...)` and a removal date.
|