- Recreate fields, states, labels, and docs by hand
- Paste issue context into each coding-agent task
- Discover drift only when the workflow feels wrong
- Trust backups without a controlled restore
- Keep upgrade and recovery knowledge in one person's head
Plane StewardProposed v0.1 · not deployed
Make Plane useful without becoming its sysadmin.
Plane Steward is the first usable-shaped slice of Trellis: one existing Plane service, one real project, and one path from adoption through daily agent work to tested exit.
plane-steward / observeread-only
plane.timleers.comexisting service · adoption target
unverified- service version
- to observe
- credential scope
- to verify
- backup boundary
- whole instance candidate
- dogfood project
- founder decision
- write authority
- none
First contact discovers reality and writes no payload state.
- Candidate payload
- 1 existing Plane service
- Daily boundary
- 1 selected project
- Pilot
- 30 days proposed
- Production writes
- Not authorized
The pain it removes
Project management should not create project-management work.
For a solo studio, the drag is not moving cards. It is recreating project structure, keeping configuration understandable, carrying issue context into coding-agent work, and knowing whether the service can actually recover.
- Reconcile one project from reviewed desired state
- Generate a bounded task packet from authoritative context
- Preview and reverse one visible customization
- Observe health, version, drift, backup, and cost
- Restore and export through a documented runbook
The first complete journey
From “adopt” to “I can leave.”
No reinstall. No unrelated project changes. No invisible production mutation.
- 01
read only
Adopt the service
Discover the existing Plane version, topology, API coverage, project boundary, credential scope, and backup granularity without changing payload state.
Output · observed-state report - 02
review
Declare one project
Capture the desired states, labels, modules, fields, links, and agent context sources in versioned configuration that contains no secrets or company content.
Output · reviewable project profile - 03
bounded write
Create or reconcile
Preview the difference, protect unrelated projects, request the required authority, apply only the selected project changes, and return durable Plane identifiers.
Output · diff, receipts, observed state - 04
daily use
Start agent work
Choose a work item and generate a bounded packet with acceptance, relevant decisions, source links, and declared permissions for a local coding agent.
Output · inspectable task packet - 05
customize
Reshape the workflow
Ask for a visible business change, preview it in an isolated environment, validate it against the pinned Plane version, approve it, then prove rollback.
Output · versioned change and return path - 06
operate
Keep watch
Observe health, version, configuration drift, backup age, resource use, and incidents. Escalate decisions instead of turning every observation into an alert.
Output · weekly operator brief - 07
exit
Recover and export
Restore the approved service boundary into a controlled recovery environment, verify the selected project, and export its records and configuration in declared formats.
Output · tested recovery and exit evidence
What the first version contains
A thin product, not a thin promise.
No-write adoption
Authenticated discovery records effective scope and fails closed when the service boundary cannot be proven.
Desired project state
One project profile becomes reviewable input for planning, preview, reconciliation, and drift detection.
Agent task packets
A local coding agent receives only the work, decisions, source links, and authority required for one bounded task.
Versioned customization
One founder-visible Plane change is proposed, isolated, validated, applied with approval, and reversed.
Operator view
Health, version, cost, backup, drift, pending decisions, and recent receipts answer what needs attention.
Restore-backed exit
Upgrade rollback means restoring known-good state; portability means verifying the export, not finding a button.
Proposed usability thresholds
Judge the wedge by founder attention, not demo applause.
These are review targets from the current plan, not measured results or approved commitments. The feasibility spike can revise or stop them.
- ≤ 10 minproject creation
- From an approved profile to a usable selected project.
- ≤ 5 minfounder attention
- For the routine create-or-reconcile journey.
- ≤ 30 minweekly operations
- For health, backup, drift, and decision review.
- ≤ 24 hrecovery point
- Maximum proposed data-loss window.
- ≤ 4 hrecovery time
- Maximum proposed time to a usable restored boundary.
- 30 daysdogfood
- Required operating record before a usable verdict.
Honest boundary
This page describes the product to build.
It does not mean Plane Steward is installed, production-authorized, or safe to point at real company data. The current executable evidence uses filesystem and SQLite fixtures—not Plane.
- No live Plane adapter
- No real human approval UI
- No production backup or restore
- No measured savings
- No security or sovereignty proof
- No 30-day operating record
Frequently challenged
Why start here?
Why only Plane?
One real application exposes API, credential, upgrade, restore, isolation, and support reality early. A second payload is useful only if it proves the same core can extend through an adapter rather than a fork.
Will this replace a paid subscription?
Not necessarily. The current Plane service is already self-hosted, so v0.1 may first prove reduced operational attention and better agent context. The founder must decide whether named subscription retirement is required for success.
Does it modify all Plane projects?
The intended boundary is one selected dogfood project. The feasibility spike must prove effective credential scope and protection for unrelated projects before any production mutation is authorized.
Can the AI change fields by itself?
It can propose a versioned change. Validation, isolation, authority, application, observation, and rollback are separate deterministic steps; the exact live mechanism is not yet implemented.
What comes immediately after?
Forgejo is the v0.2 candidate because it adds a heterogeneous developer payload and tests work-to-code causality without jumping to the whole company suite.