GriffinGuard maintains the core Griffino platform and the resources needed to grow its plugin ecosystem: the runtime, SDKs, schemas, official plugin registry, submission flow, example plugins, documentation, and design assets.

Our goal is to make local plugins work more like a real ecosystem. A plugin should be able to declare what it provides, declare what it needs, and connect through stable capability contracts instead of hard-coded integrations.

Griffino is the flagship project of GriffinGuard.

It is both:

• An open plugin routing standard - plugins declare provided and consumed capabilities through manifests and shared schemas.
• A local runtime implementation - the Griffino daemon runs plugin containers, manages configuration, routes messages, schedules work, and exposes a web console and CLI.

Key parts of Griffino include:

• Capability-based provider and consumer routing.
• Local plugin lifecycle management.
• Docker-based plugin execution.
• Web console and CLI control surfaces.
• Blueprint task scheduling.
• Plugin registry integration.
• Metrics, tracing, and operational tooling.

flowchart LR
    Org["GriffinGuard"] --> Main["Griffino"]
    Org --> SDK["Griffino-Go"]
    Org --> Schemas["Griffino-Schemas"]
    Org --> Registry["Griffino-Plugins"]
    Org --> Submit["Griffino-Plugins-Submit"]
    Org --> AI["Griffino-AI"]
    Org --> Site["Griffino-Website"]

    Main --> Daemon["Daemon"]
    Main --> CLI["CLI"]
    Main --> Console["Web console"]
    Main --> Scheduler["Blueprint scheduler"]
    Main --> Router["Capability router"]

    SDK --> Plugins["Plugin authors"]
    Schemas --> Contracts["Capability contracts"]
    Submit --> Registry
    Registry --> Main
    AI --> Plugins

Start with the main project:

brew install GriffinGuard/tap/griffino
griffino daemon

Then open the local console:

http://127.0.0.1:7070

Use the Go SDK to build plugins:

go get github.com/GriffinGuard/Griffino-Go

Useful starting points:

• Read the main runtime documentation in Griffino.
• Use Griffino-Go / Griffino-Python for plugin development.
• Define shared capability contracts in Griffino-Schemas.
• Submit official plugin registry updates through Griffino-Plugins-Submit.

• Open standards - capability contracts should be stable, inspectable, and independent of one implementation.
• Local control - users should keep their runtime, credentials, plugin state, and configuration on their own machine.
• Composable plugins - plugins should connect by what they can do, not by private knowledge of each other.
• Auditable distribution - official plugin metadata and image references should be reviewed and traceable.
• Practical developer experience - SDKs and docs should make real plugin development straightforward.