Persona: The Plugin Developer¶

Summary¶

An open-source contributor and hobbyist developer who builds integrations and plugins for communities they care about. They run Loryth locally for development but don't necessarily use it as their daily driver. They're drawn to the platform's architecture, API design, and plugin extensibility — and they want to build tools that other Loryth users will benefit from.

Demographics¶

• Age range: 22-38
• Occupation: Software developer (junior to senior), CS student, or hobbyist
• Technical comfort: Expert
• Household: Lives alone, with roommates, or with a partner
• Devices: Linux or macOS development machine, multiple monitors

Goals¶

• Build and publish plugins that extend Loryth for specific communities or use cases
• Understand the platform's architecture deeply enough to contribute meaningful features
• Have a well-documented API with predictable conventions and good error messages
• Ship integrations with external tools (calendar sync, bank imports, Obsidian bridge)

Frustrations¶

• Many open-source platforms have poor developer documentation and inconsistent APIs
• Plugin systems that are technically possible but practically undiscoverable
• Lack of local development tooling — slow feedback loops kill motivation
• Breaking API changes without migration guides or versioning

Loryth Usage¶

• Self-hosting reality: Runs the full Docker Compose stack locally for development; does not use Loryth as their primary productivity tool
• Primary device: Development machine (web app + API explorer)
• Usage frequency: Intermittent — active during development sprints, quiet between projects
• Typical session: Spin up the stack, read API docs, implement against a service endpoint, run integration tests, tear down

Key Scenarios¶

Scenario 1: Building a Bank Import Plugin¶

Wants to build a plugin that imports bank transactions into the wallet service. Reads the wallet API documentation, understands the transaction model and currency handling. Implements a CLI tool that parses CSV exports from their bank and creates transactions via the API. Publishes the tool on GitHub with instructions for other users.

Scenario 2: Contributing a KB-Obsidian Sync Bridge¶

Notices that multiple community members want to sync their Obsidian vaults with the KB service. Studies the KB sync API and document revision model. Builds a bidirectional sync tool that maps Obsidian markdown files to KB entries. Submits it as a community plugin and writes a tutorial.

Scenario 3: Investigating a Bug Report¶

A user reports that the issues service returns incorrect workflow transitions. Clones the repo, reads the relevant TD and ADR for context, reproduces the bug with an integration test, identifies the root cause in the workflow aggregate, and opens a PR with a fix and regression test.

Relevant Services¶