@dp-pcs/ogp 0.5.0 → 0.7.0-rc.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +47 -11
- package/dist/cli/agent-targeting.d.ts +21 -0
- package/dist/cli/agent-targeting.d.ts.map +1 -0
- package/dist/cli/agent-targeting.js +44 -0
- package/dist/cli/agent-targeting.js.map +1 -0
- package/dist/cli/config.d.ts +4 -0
- package/dist/cli/config.d.ts.map +1 -1
- package/dist/cli/config.js +48 -0
- package/dist/cli/config.js.map +1 -1
- package/dist/cli/federation.d.ts +6 -1
- package/dist/cli/federation.d.ts.map +1 -1
- package/dist/cli/federation.js +222 -92
- package/dist/cli/federation.js.map +1 -1
- package/dist/cli/keychain.d.ts +22 -0
- package/dist/cli/keychain.d.ts.map +1 -0
- package/dist/cli/keychain.js +213 -0
- package/dist/cli/keychain.js.map +1 -0
- package/dist/cli/project.d.ts +1 -0
- package/dist/cli/project.d.ts.map +1 -1
- package/dist/cli/project.js +87 -7
- package/dist/cli/project.js.map +1 -1
- package/dist/cli/setup.d.ts +37 -0
- package/dist/cli/setup.d.ts.map +1 -1
- package/dist/cli/setup.js +130 -0
- package/dist/cli/setup.js.map +1 -1
- package/dist/cli.js +48 -7
- package/dist/cli.js.map +1 -1
- package/dist/daemon/heartbeat.d.ts +37 -0
- package/dist/daemon/heartbeat.d.ts.map +1 -1
- package/dist/daemon/heartbeat.js +195 -21
- package/dist/daemon/heartbeat.js.map +1 -1
- package/dist/daemon/keypair.d.ts.map +1 -1
- package/dist/daemon/keypair.js +144 -22
- package/dist/daemon/keypair.js.map +1 -1
- package/dist/daemon/message-handler.d.ts +8 -0
- package/dist/daemon/message-handler.d.ts.map +1 -1
- package/dist/daemon/message-handler.js +77 -20
- package/dist/daemon/message-handler.js.map +1 -1
- package/dist/daemon/notify.d.ts +6 -0
- package/dist/daemon/notify.d.ts.map +1 -1
- package/dist/daemon/notify.js +9 -2
- package/dist/daemon/notify.js.map +1 -1
- package/dist/daemon/openclaw-bridge.d.ts +6 -0
- package/dist/daemon/openclaw-bridge.d.ts.map +1 -1
- package/dist/daemon/openclaw-bridge.js +10 -2
- package/dist/daemon/openclaw-bridge.js.map +1 -1
- package/dist/daemon/peers.d.ts +31 -0
- package/dist/daemon/peers.d.ts.map +1 -1
- package/dist/daemon/peers.js +66 -4
- package/dist/daemon/peers.js.map +1 -1
- package/dist/daemon/projects.d.ts +9 -1
- package/dist/daemon/projects.d.ts.map +1 -1
- package/dist/daemon/projects.js +2 -1
- package/dist/daemon/projects.js.map +1 -1
- package/dist/daemon/rendezvous.d.ts.map +1 -1
- package/dist/daemon/rendezvous.js +9 -7
- package/dist/daemon/rendezvous.js.map +1 -1
- package/dist/daemon/reply-handler.d.ts.map +1 -1
- package/dist/daemon/reply-handler.js +2 -1
- package/dist/daemon/reply-handler.js.map +1 -1
- package/dist/daemon/scopes.d.ts +8 -0
- package/dist/daemon/scopes.d.ts.map +1 -1
- package/dist/daemon/scopes.js.map +1 -1
- package/dist/daemon/server.d.ts +128 -1
- package/dist/daemon/server.d.ts.map +1 -1
- package/dist/daemon/server.js +304 -57
- package/dist/daemon/server.js.map +1 -1
- package/dist/shared/config.d.ts +93 -0
- package/dist/shared/config.d.ts.map +1 -1
- package/dist/shared/config.js +111 -0
- package/dist/shared/config.js.map +1 -1
- package/dist/shared/help.js +2 -0
- package/dist/shared/help.js.map +1 -1
- package/dist/shared/signing.d.ts +49 -0
- package/dist/shared/signing.d.ts.map +1 -1
- package/dist/shared/signing.js +68 -0
- package/dist/shared/signing.js.map +1 -1
- package/dist/shared/tls.d.ts +27 -0
- package/dist/shared/tls.d.ts.map +1 -0
- package/dist/shared/tls.js +37 -0
- package/dist/shared/tls.js.map +1 -0
- package/docs/ARCHITECTURE.md +146 -0
- package/docs/CLI-REFERENCE.md +170 -2
- package/docs/MULTI-AGENT-PERSONAS-DESIGN.md +925 -0
- package/package.json +1 -1
- package/scripts/completion.bash +26 -2
- package/scripts/completion.zsh +10 -4
- package/scripts/render-ogp-overview-video.mjs +417 -0
- package/skills/ogp/SKILL.md +1 -1
- package/skills/ogp-expose/SKILL.md +1 -1
- package/skills/ogp-project/SKILL.md +1 -1
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
# OGP Architecture
|
|
2
|
+
|
|
3
|
+
> Open Gateway Protocol — the *why* behind the daemon. For the *how*, see [`PROTOCOL.md`](./PROTOCOL.md). For commands, see [`CLI-REFERENCE.md`](./CLI-REFERENCE.md).
|
|
4
|
+
|
|
5
|
+
## What OGP Is
|
|
6
|
+
|
|
7
|
+
OGP is a vendor-neutral federation protocol that lets two AI gateway systems, owned by different people or organizations, exchange structured agent messages with explicit trust, scoped permissions, and controlled information boundaries — without either party acting as a relay or sharing credentials.
|
|
8
|
+
|
|
9
|
+
In plain terms: your AI assistant can call your colleague's AI assistant directly. Neither of you has to copy-paste messages between them.
|
|
10
|
+
|
|
11
|
+
OGP is not tied to any specific AI platform. The reference implementation runs alongside OpenClaw and Hermes today, but the protocol itself is implementation-agnostic. Any agentic system that exposes a gateway boundary can implement OGP and federate with any other OGP-compliant gateway.
|
|
12
|
+
|
|
13
|
+
## Why "Open"
|
|
14
|
+
|
|
15
|
+
The name is intentional. OGP is:
|
|
16
|
+
|
|
17
|
+
- **Open standard** — the protocol specification is public, not proprietary
|
|
18
|
+
- **Open to any gateway implementation** — OpenClaw shipped the first reference implementation; the protocol belongs to no vendor
|
|
19
|
+
- **Open between humans** — federation is bilateral, human-approved, and revocable. No central authority brokers trust.
|
|
20
|
+
|
|
21
|
+
## OGP vs. A2A
|
|
22
|
+
|
|
23
|
+
OGP and Google's Agent2Agent (A2A) protocol are frequently confused but solve different problems.
|
|
24
|
+
|
|
25
|
+
| | A2A | OGP |
|
|
26
|
+
|---|---|---|
|
|
27
|
+
| **Layer** | Agent-to-agent task delegation | Gateway-to-gateway federation |
|
|
28
|
+
| **Trust model** | Service-level (API keys, JWTs, shared identity provider) | Human-level (bilateral approval, Ed25519 keypairs) |
|
|
29
|
+
| **Relationship** | Stateless request/response | Persistent, approved peering |
|
|
30
|
+
| **Scope control** | Implicit at the endpoint level | Explicit per-peer scope, rate limits, topic restrictions |
|
|
31
|
+
| **Human in the loop** | No | Yes — approval required before first message |
|
|
32
|
+
| **Designed for** | Enterprise workflow automation | Personal AI assistants and small-team collaboration |
|
|
33
|
+
|
|
34
|
+
They are complementary, not competing. An OGP-enabled gateway could use A2A internally to delegate tasks to specialized agents inside its own trust boundary. OGP handles *can these two systems trust each other and under what terms*. A2A handles the message format once they can talk.
|
|
35
|
+
|
|
36
|
+
The cleanest analogy: A2A is HTTP — request/response between services. OGP is BGP — trust and policy between autonomous systems owned by different parties.
|
|
37
|
+
|
|
38
|
+
## The BGP Parallel
|
|
39
|
+
|
|
40
|
+
OGP borrows its trust and policy model from BGP (Border Gateway Protocol), the protocol that handles routing between autonomous networks on the internet. The parallel isn't perfect (OGP doesn't compute paths or maintain route tables), but the *peering model* maps cleanly.
|
|
41
|
+
|
|
42
|
+
| BGP Concept | OGP Equivalent |
|
|
43
|
+
|---|---|
|
|
44
|
+
| Autonomous System (AS) | Individual gateway (identified by Ed25519 public-key prefix) |
|
|
45
|
+
| OPEN message | `GET /.well-known/ogp` |
|
|
46
|
+
| BGP session establishment | `request` → human approval → `approve` exchange |
|
|
47
|
+
| Route policy / filters | Per-peer scope grants (which intents are allowed) |
|
|
48
|
+
| MD5 session auth | Ed25519 signed messages |
|
|
49
|
+
| Route dampening | Per-peer sliding-window rate limiting |
|
|
50
|
+
| iBGP (interior) | Agent-to-agent within one gateway |
|
|
51
|
+
| eBGP (exterior) | OGP — between different people's gateways |
|
|
52
|
+
| BGP WITHDRAW | Federation revocation (peer marked `removed`, lifecycle → `tombstoned`) |
|
|
53
|
+
| BGP neighbor states (`Idle`/`Active`/`OpenSent`/`Established`) | OGP federation states (`init`/`twoWay`/`established`/`degraded`/`down`/`tombstoned`) |
|
|
54
|
+
|
|
55
|
+
What OGP **does not** borrow from BGP: multi-hop routing, route tables, path computation, convergence. OGP is strictly point-to-point peering between two gateways. BGP started the same way.
|
|
56
|
+
|
|
57
|
+
## Four Design Principles
|
|
58
|
+
|
|
59
|
+
**1. Decentralized.** No central registry or authority. You share your gateway URL out-of-band (Telegram, email, an invite token through the optional rendezvous server). The protocol handles everything from there. Any gateway can peer with any other OGP-compliant gateway without asking a third party.
|
|
60
|
+
|
|
61
|
+
**2. Policy-driven.** Every relationship has explicit, bilateral scope. Nothing flows without a configured policy on both ends. You decide what their gateway can ask yours to do; they decide what yours can ask theirs.
|
|
62
|
+
|
|
63
|
+
**3. Session-oriented.** Trust is established once (the handshake), then messages flow within that relationship until explicitly revoked. No re-authentication on every message. The federation lifecycle state machine tracks the relationship over time.
|
|
64
|
+
|
|
65
|
+
**4. Graceful teardown.** Either party can revoke at any time. Revocation is immediate, cryptographically clean, and tombstoned — re-federation from a removed peer creates a fresh `init`-state pending record, never a silent re-trust.
|
|
66
|
+
|
|
67
|
+
## Architecture
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
┌─────────────────────────────────┐ ┌─────────────────────────────────┐
|
|
71
|
+
│ Gateway A (David) │ │ Gateway B (Stan) │
|
|
72
|
+
│ publicKey: 302a300506032b65... │ │ publicKey: 1a2b3c4d5e6f7890... │
|
|
73
|
+
│ │ │ │
|
|
74
|
+
│ ┌──────────┐ ┌─────────────┐ │ │ ┌──────────┐ ┌─────────────┐ │
|
|
75
|
+
│ │ Junior │ │ Sterling │ │ │ │ Stan's │ │ Stan's │ │
|
|
76
|
+
│ │ (main) │ │ (finance) │ │ │ │ agent │ │ agents │ │
|
|
77
|
+
│ └────┬─────┘ └─────────────┘ │ │ └────┬─────┘ └─────────────┘ │
|
|
78
|
+
│ │ intra-gateway comms │ │ │ intra-gateway comms │
|
|
79
|
+
│ └──── (iBGP analog) ──────┤ ├───────┴── (iBGP analog) ────────┤
|
|
80
|
+
│ │ │ │
|
|
81
|
+
│ OGP Policy: │ │ OGP Policy: │
|
|
82
|
+
│ • Stan: scope=agent-comms │◄──OGP──►│ • David: scope=agent-comms │
|
|
83
|
+
│ + project.contribute │ │ + project.contribute │
|
|
84
|
+
│ • Rate: 100/3600 per intent │ │ • Rate: 100/3600 per intent │
|
|
85
|
+
│ • Auth: Ed25519 per message │ │ • Auth: Ed25519 per message │
|
|
86
|
+
│ │ │ │
|
|
87
|
+
└─────────────────────────────────┘ └─────────────────────────────────┘
|
|
88
|
+
|
|
89
|
+
Both gateways implement OGP. Neither knows nor cares what
|
|
90
|
+
framework the other is built on.
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
## Trust Boundaries
|
|
94
|
+
|
|
95
|
+
The gateway is the trust boundary. Agents never leave their own gateway. The gateway controls what crosses organizational lines.
|
|
96
|
+
|
|
97
|
+
This matters for three reasons:
|
|
98
|
+
|
|
99
|
+
1. **Containment preservation.** A compromised peer agent cannot directly access your agent's tools, memory, or context. It can only send signed intents that the receiving gateway's Doorman validates.
|
|
100
|
+
|
|
101
|
+
2. **Auditability.** Every cross-gateway message is signed, logged, and attributable to a specific peer's keypair. No "the agent decided" — the human-controlled policy decided, and the agent executed.
|
|
102
|
+
|
|
103
|
+
3. **Revocability.** Trust granted in one direction can be revoked in one direction. Granular per-peer per-intent scopes can be tightened without breaking the rest of the relationship.
|
|
104
|
+
|
|
105
|
+
## Scope Model
|
|
106
|
+
|
|
107
|
+
OGP enforces scope at three layers:
|
|
108
|
+
|
|
109
|
+
```
|
|
110
|
+
Layer 1: Gateway Capabilities → What I CAN support (advertised at /.well-known/ogp)
|
|
111
|
+
Layer 2: Peer Negotiation → What I WILL grant YOU (set at approval time)
|
|
112
|
+
Layer 3: Runtime Enforcement → Is THIS request within YOUR granted scope (Doorman)
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
Capabilities can be broader than grants. Grants can be broader than runtime enforcement (if a scope is later revoked). The Doorman always enforces the most restrictive applicable layer.
|
|
116
|
+
|
|
117
|
+
For details on the validation chain, see [Five Layers of No: How OGP's Doorman Actually Works](https://trilogyai.substack.com) (linked from the article series).
|
|
118
|
+
|
|
119
|
+
## Federation Lifecycle
|
|
120
|
+
|
|
121
|
+
Every approved peer relationship transitions through an OSPF-inspired state machine:
|
|
122
|
+
|
|
123
|
+
```
|
|
124
|
+
[no peer] → init (federation request received / sent)
|
|
125
|
+
init → twoWay (peer approved)
|
|
126
|
+
twoWay → established (first bidirectional health check succeeds)
|
|
127
|
+
established → degraded (one direction fails threshold)
|
|
128
|
+
established → down (both directions fail threshold)
|
|
129
|
+
degraded → established (failures clear)
|
|
130
|
+
degraded → down (remaining direction also fails)
|
|
131
|
+
down → established (recovery)
|
|
132
|
+
any → tombstoned (peer rejected / removed)
|
|
133
|
+
[tombstoned] → init (peer re-federates as fresh pending record)
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
Each transition is logged with timestamp + reason and persisted on the peer record. See `src/daemon/peers.ts:deriveFederationState` for the canonical implementation.
|
|
137
|
+
|
|
138
|
+
## Related Documents
|
|
139
|
+
|
|
140
|
+
- [`PROTOCOL.md`](./PROTOCOL.md) — wire format, endpoints, message envelopes, signing
|
|
141
|
+
- [`scopes.md`](./scopes.md) — scope negotiation and ScopeBundle schema
|
|
142
|
+
- [`agent-comms.md`](./agent-comms.md) — delegated authority response levels
|
|
143
|
+
- [`federation-flow.md`](./federation-flow.md) — handshake walkthrough
|
|
144
|
+
- [`rendezvous.md`](./rendezvous.md) — optional rendezvous discovery and invite tokens
|
|
145
|
+
- [`MULTI-FRAMEWORK-DESIGN.md`](./MULTI-FRAMEWORK-DESIGN.md) — multi-framework architecture and meta-config registry
|
|
146
|
+
- [`extending-to-hermes.md`](./extending-to-hermes.md) — porting OGP to a non-OpenClaw framework
|
package/docs/CLI-REFERENCE.md
CHANGED
|
@@ -212,6 +212,109 @@ ogp config show
|
|
|
212
212
|
ogp --for hermes config show
|
|
213
213
|
```
|
|
214
214
|
|
|
215
|
+
### ogp config show-identity
|
|
216
|
+
|
|
217
|
+
Show current identity configuration.
|
|
218
|
+
|
|
219
|
+
**Syntax:**
|
|
220
|
+
```bash
|
|
221
|
+
ogp config show-identity [--for <framework>]
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
**Options:**
|
|
225
|
+
- `--for <framework>` - Show identity for specific framework (default: current/default)
|
|
226
|
+
|
|
227
|
+
**Example:**
|
|
228
|
+
```bash
|
|
229
|
+
ogp config show-identity
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
Displays:
|
|
233
|
+
- Human name
|
|
234
|
+
- Agent name
|
|
235
|
+
- Organization
|
|
236
|
+
- Tags
|
|
237
|
+
|
|
238
|
+
### ogp config set-identity
|
|
239
|
+
|
|
240
|
+
Update your identity information. Identity includes separate human and agent attribution.
|
|
241
|
+
|
|
242
|
+
**Syntax:**
|
|
243
|
+
```bash
|
|
244
|
+
ogp config set-identity [options] [--for <framework>]
|
|
245
|
+
```
|
|
246
|
+
|
|
247
|
+
**Options:**
|
|
248
|
+
- `--human-name <name>` - Human operator name (e.g., "David Proctor")
|
|
249
|
+
- `--agent-name <name>` - Agent name (e.g., "Junior", "Apollo")
|
|
250
|
+
- `--organization <org>` - Organization (e.g., "Trilogy", "AICOE")
|
|
251
|
+
- `--for <framework>` - Framework to configure (default: current/default)
|
|
252
|
+
|
|
253
|
+
**Examples:**
|
|
254
|
+
```bash
|
|
255
|
+
# Set human name
|
|
256
|
+
ogp config set-identity --human-name "David Proctor"
|
|
257
|
+
|
|
258
|
+
# Set agent name
|
|
259
|
+
ogp config set-identity --agent-name "Junior"
|
|
260
|
+
|
|
261
|
+
# Set organization
|
|
262
|
+
ogp config set-identity --organization "Trilogy"
|
|
263
|
+
|
|
264
|
+
# Set multiple fields at once
|
|
265
|
+
ogp config set-identity \
|
|
266
|
+
--human-name "David Proctor" \
|
|
267
|
+
--agent-name "Junior" \
|
|
268
|
+
--organization "Trilogy"
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
**Note:** After updating identity, use `ogp federation update-identity <peer-id>` to send the updated information to existing federated peers.
|
|
272
|
+
|
|
273
|
+
### ogp config set-tags
|
|
274
|
+
|
|
275
|
+
Set tags (replaces existing).
|
|
276
|
+
|
|
277
|
+
**Syntax:**
|
|
278
|
+
```bash
|
|
279
|
+
ogp config set-tags <tags> [--for <framework>]
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
**Arguments:**
|
|
283
|
+
- `<tags>` - Comma-separated list of tags
|
|
284
|
+
|
|
285
|
+
**Example:**
|
|
286
|
+
```bash
|
|
287
|
+
ogp config set-tags work,production,client-trilogy
|
|
288
|
+
```
|
|
289
|
+
|
|
290
|
+
### ogp config add-tag
|
|
291
|
+
|
|
292
|
+
Add a single tag.
|
|
293
|
+
|
|
294
|
+
**Syntax:**
|
|
295
|
+
```bash
|
|
296
|
+
ogp config add-tag <tag> [--for <framework>]
|
|
297
|
+
```
|
|
298
|
+
|
|
299
|
+
**Example:**
|
|
300
|
+
```bash
|
|
301
|
+
ogp config add-tag testing
|
|
302
|
+
```
|
|
303
|
+
|
|
304
|
+
### ogp config remove-tag
|
|
305
|
+
|
|
306
|
+
Remove a single tag.
|
|
307
|
+
|
|
308
|
+
**Syntax:**
|
|
309
|
+
```bash
|
|
310
|
+
ogp config remove-tag <tag> [--for <framework>]
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
**Example:**
|
|
314
|
+
```bash
|
|
315
|
+
ogp config remove-tag testing
|
|
316
|
+
```
|
|
317
|
+
|
|
215
318
|
## Daemon Management
|
|
216
319
|
|
|
217
320
|
### ogp start
|
|
@@ -570,6 +673,43 @@ ogp federation alias 302a300506... apollo
|
|
|
570
673
|
ogp federation alias apollo big-papa
|
|
571
674
|
```
|
|
572
675
|
|
|
676
|
+
### ogp federation update-identity
|
|
677
|
+
|
|
678
|
+
Send updated identity information to an approved peer.
|
|
679
|
+
|
|
680
|
+
**Syntax:**
|
|
681
|
+
```bash
|
|
682
|
+
ogp federation update-identity <peer-id> [--for <framework>]
|
|
683
|
+
```
|
|
684
|
+
|
|
685
|
+
**Arguments:**
|
|
686
|
+
- `<peer-id>` - Peer identifier or alias
|
|
687
|
+
|
|
688
|
+
**Options:**
|
|
689
|
+
- `--for <framework>` - Framework to use (default: current/default)
|
|
690
|
+
|
|
691
|
+
**Description:**
|
|
692
|
+
|
|
693
|
+
After updating your identity with `ogp config set-identity`, use this command to send the updated information to existing federated peers. This updates:
|
|
694
|
+
|
|
695
|
+
- Human name
|
|
696
|
+
- Agent name
|
|
697
|
+
- Organization
|
|
698
|
+
- Display name
|
|
699
|
+
|
|
700
|
+
The peer must be in `approved` status. New federations automatically include identity during the initial request.
|
|
701
|
+
|
|
702
|
+
**Examples:**
|
|
703
|
+
```bash
|
|
704
|
+
# Update identity for a specific peer
|
|
705
|
+
ogp federation update-identity apollo
|
|
706
|
+
|
|
707
|
+
# Update identity for a peer using their full ID
|
|
708
|
+
ogp federation update-identity 302a300506032b6570032100...
|
|
709
|
+
```
|
|
710
|
+
|
|
711
|
+
**Note:** Identity updates require v0.5.0 or later on both sides.
|
|
712
|
+
|
|
573
713
|
### ogp federation ping
|
|
574
714
|
|
|
575
715
|
Test connectivity to a peer gateway.
|
|
@@ -927,11 +1067,11 @@ ogp --for all project list
|
|
|
927
1067
|
|
|
928
1068
|
### ogp project contribute
|
|
929
1069
|
|
|
930
|
-
Add a contribution to a project.
|
|
1070
|
+
Add a contribution to a project with identity attribution.
|
|
931
1071
|
|
|
932
1072
|
**Syntax:**
|
|
933
1073
|
```bash
|
|
934
|
-
ogp project contribute <id> <type> <summary> [--for <framework>]
|
|
1074
|
+
ogp project contribute <id> <type> <summary> [options] [--for <framework>]
|
|
935
1075
|
```
|
|
936
1076
|
|
|
937
1077
|
**Arguments:**
|
|
@@ -939,12 +1079,38 @@ ogp project contribute <id> <type> <summary> [--for <framework>]
|
|
|
939
1079
|
- `<type>` - Entry type: `progress`, `decision`, `blocker`, `context`
|
|
940
1080
|
- `<summary>` - Contribution summary
|
|
941
1081
|
|
|
1082
|
+
**Options:**
|
|
1083
|
+
- `--metadata <json>` - Additional structured data as JSON
|
|
1084
|
+
- `--local-only` - Skip auto-push to federated project members
|
|
1085
|
+
- `--for <framework>` - Framework to use (default: current/default)
|
|
1086
|
+
|
|
1087
|
+
**Identity Snapshots (v0.6.0+):**
|
|
1088
|
+
|
|
1089
|
+
Contributions automatically capture your identity at the time of contribution, including:
|
|
1090
|
+
- Human name
|
|
1091
|
+
- Agent name
|
|
1092
|
+
- Organization
|
|
1093
|
+
- Tags
|
|
1094
|
+
|
|
1095
|
+
This preserves accurate attribution even if you later change your identity settings. Configure your identity with:
|
|
1096
|
+
|
|
1097
|
+
```bash
|
|
1098
|
+
ogp config set-identity --human-name "Your Name" --agent-name "Agent"
|
|
1099
|
+
```
|
|
1100
|
+
|
|
942
1101
|
**Examples:**
|
|
943
1102
|
```bash
|
|
944
1103
|
ogp project contribute expense-app progress "Completed authentication system"
|
|
945
1104
|
ogp project contribute expense-app decision "Using PostgreSQL for persistence"
|
|
946
1105
|
ogp project contribute expense-app blocker "Waiting for API key approval"
|
|
947
1106
|
ogp project contribute expense-app context "Target users: small business owners"
|
|
1107
|
+
|
|
1108
|
+
# With metadata
|
|
1109
|
+
ogp project contribute expense-app progress "v1.0 shipped" \
|
|
1110
|
+
--metadata '{"version":"1.0.0","users":150}'
|
|
1111
|
+
|
|
1112
|
+
# Local only (no federation sync)
|
|
1113
|
+
ogp project contribute expense-app progress "WIP feature" --local-only
|
|
948
1114
|
```
|
|
949
1115
|
|
|
950
1116
|
### ogp project query
|
|
@@ -1155,6 +1321,8 @@ ogp intent remove deployment
|
|
|
1155
1321
|
|
|
1156
1322
|
Start a public tunnel to expose the daemon to the internet.
|
|
1157
1323
|
|
|
1324
|
+
**Note:** This command is **optional**. Only use it if you need help getting public access to your gateway. If you already have a publicly accessible URL (cloud server, VPS, reverse proxy, etc.), just set your `gatewayUrl` in the config and skip this command.
|
|
1325
|
+
|
|
1158
1326
|
**Syntax:**
|
|
1159
1327
|
```bash
|
|
1160
1328
|
ogp expose [--background] [--method <method>] [--for <framework>]
|