A small TreeSeed site that doubles as documentation and a real test ground.
TreeSeed works best when contributors can understand the package, inspect the tenant surface, and verify real workflows without reconstructing everything from source code alone. This fixture keeps those paths visible by combining pages, questions, objectives, proposals, decisions, books, agents, and forms in one generic working site.
Right now
- A full TreeSeed content surface with pages, notes, questions, objectives, proposals, decisions, people, agents, books, and docs.
- Package defaults exercised through a realistic tenant instead of isolated unit tests alone.
- Forms, book exports, and navigation paths that participate in release verification.
- A documentation-first example meant to stay easy to inspect and easy to maintain.
What TreeSeed Is
A working site for documentation, management, and verification
TreeSeed is easiest to understand when the package runtime and the tenant experience are visible together. The fixture exists to make that relationship concrete.
The site is intentionally generic. It is not here to tell one project’s story. It is here to show how TreeSeed can organize content, contributor roles, inquiry, and operational guidance in a way that remains legible as the package evolves.
That makes the fixture useful in two directions at once. It teaches contributors how TreeSeed is meant to feel from the tenant side, and it gives maintainers a broad surface that can catch regressions in shared pages, content wiring, book exports, and forms behavior.
What Makes It Useful
The site keeps docs, inquiry, and operations in the same surface
The fixture is designed to show how TreeSeed can turn scattered workflow concepts into one inspectable tenant.
Content commitments
- Questions, objectives, proposals, and decisions stay visible instead of disappearing into process notes.
- Books and docs remain queryable content, not only navigation configuration.
- People and agents are explicit contributors rather than invisible supporting actors.
- Notes can still capture evidence and rationale without replacing proposal and decision records.
Execution posture
- The fixture participates directly in `check`, `build`, and smoke verification.
- Shared defaults should read clearly in a generic tenant, not only in package code.
- Generated book exports and forms flows are part of the package contract.
- Contributor understanding is treated as an engineering concern, not polish for later.
What Exists Today
A realistic tenant that stays intentionally generic
The fixture is broad enough to exercise the package meaningfully, but it stays small enough to remain maintainable and easy to read.
The current fixture demonstrates the full TreeSeed surface: pages, notes, questions, objectives, proposals, decisions, people, agents, books, docs, and forms. That gives package changes a tenant-level target instead of relying on isolated examples.
It is still a fixture, not a turnkey product site. The goal is to make development and management easier by keeping one coherent example current, not to simulate every possible downstream use case.
Best current shorthand
Documentation-first example, real enough to break usefully.
If you want the evidence behind that judgment, the Project Status page is the right next step.
How To Read The Site
Follow the path that matches the question you have
Each public page has a single job: explain the platform, ground it in implementation reality, define active work, or make collaboration legible.
Why this fixture exists
Vision
Start with the reason TreeSeed keeps a generic working site in the repo.
Open path
What the fixture proves today
Status
See which package surfaces the fixture is expected to exercise and why that matters.
Open path
What questions organize the work
Research Direction
Follow the implementation-facing questions that keep the fixture useful.
Open path
How to enter the docs surface
Architecture
Use the bridge page to move into the books and deeper knowledge library.
Open path
How to help usefully
Contribute
Find the most useful contribution lanes for a documentation-first TreeSeed site.
Open path
Useful feedback
The most helpful feedback is concrete: which defaults still feel confusing, which workflows are hard to infer, and which parts of the fixture are too thin or too heavy to serve as a reliable test ground.
Notes
Working notes instead of polished announcements
Notes are the lightest-weight way to explain why the fixture changed, what was learned, and where contributor guidance still needs work.
TreeSeed
Questions, objectives, proposals, decisions, contributors, and books form one connected working surface
The fixture shows how humans and agents can publish questions, anchor them to objectives, turn them into proposals, and record decisions without losing the surrounding context.
Questions
Open inquiry
Questions make the active lines of curiosity explicit instead of leaving them implied in notes or book chapters.
Objectives
Guided direction
Objectives show where the fixture is concentrating effort right now and how that effort relates to contributor experience and package verification.
Proposals
Suggested change
Proposals make the next suggested move explicit instead of leaving it scattered across notes or implied by workstream activity.
Decisions
Chosen path
Decisions record what was actually accepted, deferred, rejected, or superseded so the site can accumulate institutional memory instead of only discussion.
Contributors
People and agents are first-class participants
The hub makes both human and agent contributors visible so authorship, stewardship, and inquiry relationships can stay inspectable over time.
Books
Books are queryable working references
Long-form books stay grounded in the knowledge library while remaining visible as first-class TreeSeed records.