File size: 2,644 Bytes
6a7089a
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
# System Charts

This page collects the main high-level charts for the current PinchTab architecture.

## Chart 1: Product Shape

```mermaid
flowchart TD
    U["Agent / CLI / Tool"] --> S["PinchTab Server"]

    S --> D["Dashboard + Config + Profiles API"]
    S --> O["Orchestrator + Strategy Layer"]

    O --> M1["Managed Instance"]
    O --> M2["Managed Instance"]

    M1 --> B1["pinchtab bridge"]
    M2 --> B2["pinchtab bridge"]

    B1 --> C1["Chrome"]
    B2 --> C2["Chrome"]

    C1 --> T1["Tabs"]
    C2 --> T2["Tabs"]

    S -. "advanced attach path" .-> E["Registered External Chrome"]
```

This is the default system shape today:

- agents talk to the server over HTTP
- the server manages profiles, instances, and routing
- managed instances are bridge-backed
- attach exists as an advanced external-browser registration path

## Chart 2: Primary Usage Path

```mermaid
flowchart LR
    I["Install PinchTab"] --> R["Run: pinchtab"]
    R --> L["Local server on localhost:9867"]
    L --> A["Agent / CLI sends HTTP requests"]
    A --> W["Browser work happens through PinchTab"]
```

This is the normal mental model for users. Most users should think about `pinchtab`, not `pinchtab bridge`.

## Chart 3: Runtime Shapes

```mermaid
flowchart LR
    subgraph S1["Server Mode"]
        C1["Client"] --> P1["pinchtab server"]
        P1 --> B1["pinchtab bridge"]
        B1 --> CH1["Chrome"]
        CH1 --> T1["Tabs"]
    end

    subgraph S2["Bridge Mode"]
        C2["Client"] --> B2["pinchtab bridge"]
        B2 --> CH2["Chrome"]
        CH2 --> T2["Tabs"]
    end
```

Meaning:

- **server mode** is the multi-instance control-plane path
- **bridge mode** is the single-instance browser runtime

## Chart 4: Current Request Paths

```mermaid
flowchart TD
    R["HTTP Request"] --> M["Auth + Middleware"]
    M --> T{"Route Type"}

    T -->|Direct browser route| X["Tab / Instance Resolution"]
    T -->|Task route, when enabled| Q["Scheduler"]
    T -->|Attach route| A["Attach Policy Check"]

    Q --> X
    X --> H["Bridge Handler"]
    H --> P["Handler-Level Policy Checks"]
    P --> C["Chrome via CDP"]
    C --> O["JSON / Text / PDF / Image Response"]

    A --> AR["Register External Instance"]
```

Important details:

- auth and shared middleware run at the HTTP layer
- attach policy is enforced on the attach route in the server
- IDPI and similar browser-facing checks run in handlers such as navigation, text, and snapshot
- tab-scoped routes are resolved to the owning instance before execution
- the scheduler is optional, server-only, and applies to `/tasks`
- bridge handlers perform the actual browser work