This graph shows the Go packages compiled into the gr/graith executable and their direct internal imports. An arrow from package A to package B means that A imports and uses B.

Use the toolbar, mouse wheel, trackpad, or touch gestures to zoom and pan the graph. The full-screen view is useful when tracing longer dependency paths.

flowchart LR
    subgraph entrypoint["Entry point"]
        package_0["cmd/graith"]
    end
    subgraph internals["Internal packages"]
        package_1["internal/agent"]
        package_2["internal/agent/transcript"]
        package_3["internal/atomicfile"]
        package_4["internal/cli"]
        package_5["internal/client"]
        package_6["internal/config"]
        package_7["internal/cronx"]
        package_8["internal/daemon"]
        package_9["internal/daemonservice"]
        package_10["internal/detector"]
        package_11["internal/executablepin"]
        package_12["internal/git"]
        package_13["internal/headless"]
        package_14["internal/hookoutput"]
        package_15["internal/ignore"]
        package_16["internal/output"]
        package_17["internal/processidentity"]
        package_18["internal/protocol"]
        package_19["internal/pty"]
        package_20["internal/sandbox"]
        package_21["internal/scenariofile"]
        package_22["internal/sessionlabel"]
        package_23["internal/store"]
        package_24["internal/telemetry"]
        package_25["internal/testprocess"]
        package_26["internal/tools"]
        package_27["internal/version"]
    end
    package_0 --> package_4
    package_0 --> package_19
    package_4 --> package_1
    package_4 --> package_2
    package_4 --> package_5
    package_4 --> package_6
    package_4 --> package_8
    package_4 --> package_9
    package_4 --> package_12
    package_4 --> package_14
    package_4 --> package_16
    package_4 --> package_17
    package_4 --> package_18
    package_4 --> package_20
    package_4 --> package_21
    package_4 --> package_22
    package_4 --> package_23
    package_4 --> package_25
    package_4 --> package_26
    package_4 --> package_27
    package_5 --> package_1
    package_5 --> package_6
    package_5 --> package_9
    package_5 --> package_17
    package_5 --> package_18
    package_5 --> package_19
    package_5 --> package_22
    package_5 --> package_25
    package_5 --> package_27
    package_6 --> package_7
    package_6 --> package_26
    package_8 --> package_2
    package_8 --> package_3
    package_8 --> package_6
    package_8 --> package_7
    package_8 --> package_9
    package_8 --> package_10
    package_8 --> package_11
    package_8 --> package_12
    package_8 --> package_13
    package_8 --> package_15
    package_8 --> package_17
    package_8 --> package_18
    package_8 --> package_19
    package_8 --> package_20
    package_8 --> package_21
    package_8 --> package_22
    package_8 --> package_23
    package_8 --> package_24
    package_8 --> package_25
    package_8 --> package_26
    package_8 --> package_27
    package_9 --> package_1
    package_9 --> package_6
    package_9 --> package_19
    package_9 --> package_25
    package_12 --> package_26
    package_13 --> package_19
    package_17 --> package_26
    package_20 --> package_26
    package_21 --> package_6
    package_21 --> package_18
    package_23 --> package_3
    package_23 --> package_26
    package_25 --> package_1
    classDef entry fill:#7c3aed,color:#fff,stroke:#5b21b6,stroke-width:2px
    class package_0 entry

Scroll or pinch to zoom, drag to pan, or focus the graph and use +, −, arrow keys, and 0.

The graph is generated for the canonical linux/amd64 build with CGO disabled. Standard-library and third-party dependencies are omitted, as are test-only and integration-test packages. Runtime communication that is not represented by a Go import—such as framed socket traffic between the client and daemon—belongs in the main architecture overview.

Generation

The canonical Hugo data is committed at website/data/package_dependencies.json so package-structure changes have a reviewable diff. Regenerate it from the repository root whenever packages or their imports change:

  make package-graph

CI runs make package-graph-check and rejects stale output without modifying the tracked file. Documentation builds consume the committed data as-is:

  make docs

The component dependency contract is checked separately because it includes test-only imports and ownership metadata that the visualization omits. Run make architecture-check after changing package boundaries. The checked-in policy is internal/architecture/manifest.json, and every package must have a category and accountable owner. A new package is not complete until it is classified there. The current ratchet is zero forbidden edges and zero active exceptions; an import that crosses a forbidden boundary fails CI. Exceptions are temporary migration records only: they must name an owner, explain the contract being migrated, and have a future expiry date. Expired exceptions fail the check rather than silently becoming baseline debt.

The manifest and analyzer are the enforcement source. The generated graph is only a canonical, production-import visualization: it intentionally omits test-only and platform-specific relationships and must never be edited by hand. Update it with make package-graph when its inputs change, then run make package-graph-check to verify drift. For boundary changes, run both checks plus the affected package tests; protocol, integration, and Swift changes require their corresponding checks as well.

For a live preview:

  make docs-serve

Refreshing native libghostty artifacts

Linux bundles are immutable release assets named libghostty-vt-linux-amd64.tar.gz and libghostty-vt-linux-arm64.tar.gz. The lock records each URL and SHA-256. CI uses scripts/libghostty-native.sh prepare-linux-artifact, which verifies the digest before extraction and then checks the manifest, target, archive member types, static-library contents, and pkg-config metadata.

For same-repository lock-only Renovate updates, review the proposal and apply the native-artifact-approved label. The trusted Publish native libghostty dependency artifacts workflow consumes that exact label event, builds both Linux targets from base-branch code, publishes immutable release assets keyed by the Ghostty, go-libghostty, and Zig inputs, and pushes the generated lock/SPDX/notices commit back to the Renovate branch. Reapply the label after a rebase or synchronize event. The workflow refuses to overwrite an existing release asset and fails closed if the selected Ghostty/Zig pair cannot be built. A mutable Actions cache is never a native-code trust boundary; use GRAITH_LIBGHOSTTY_SOURCE_BUILD=1 only for local comparison.