Proposal: first-class Idea Files that mature into projects

## Vision

**What if project management in Buzz began before there was a project?**

I want to be able to open Buzz, word-vomit everything in my head about a possible idea, and walk away.

I should not need to organize the thought, write a specification, research it, find related work, estimate the effort, or determine which team should evaluate it.

With explicit permission and workspace-defined limits, configurable agents could turn that raw thought into a living **Idea File**.

Agents could help:

- Preserve the original intent and source conversation
- Clarify the problem, opportunity, and intended outcome
- Find related ideas, discussions, and existing work
- Consolidate overlapping contributions without losing provenance
- Research evidence and counterevidence
- Explore possible approaches
- Identify assumptions, risks, costs, and dependencies
- Recommend the smallest useful proof
- Suggest the appropriate team and collaborators
- Package the result into a polished proposal

The finished Idea File could then be routed to the people best qualified to evaluate it.

A marketing idea could reach Marketing or Growth. A product feature could reach Product and Engineering. A pricing change could involve Finance, Product, and Growth.

The appropriate human could decide whether to:

- **Push** it into execution
- **Prove** it through a bounded experiment
- **Queue** it for later
- **Shelve** it until a defined trigger
- **Kill** it while retaining the rationale
- **Merge** it with related work
- Request more information

Only approved ideas would become execution work.

The Idea File would remain connected to the resulting project through planning, execution, review, completion, and outcome.

```text
Raw human thought
↓
Living Idea File
↓
Human and agent development
↓
Correct team and collaborators
↓
Polished proposal
↓
Human decision
↓
Approved project or experiment
↓
Execution and review
↓
Outcome and lessons
```

The goal is not for Buzz to prescribe one research agent, prioritization formula, or organizational process.

The goal is to give Buzz first-class primitives through which ideas can mature into projects.

> Humans should be able to think naturally. Configurable agents should be able to perform the organizational and investigative work between inspiration and execution. Buzz should preserve the complete lifecycle from the original thought to the final outcome.

## Scope of this proposal

This issue is asking whether Buzz should provide the native platform foundation for that experience:

- A durable Idea File object
- Creation from a message or conversation
- Source-message provenance
- Idea-stage lifecycle state
- Human decision records
- Relationships between ideas and resulting work
- Permission-aware sharing and routing
- A channel-native Ideas view
- Promotion into execution work
- Equivalent agent-facing operations through `buzz-cli`

Buzz would own the durable state, permissions, relationships, views, and authorization semantics.

Configurable agents and workspace workflows would provide behavior such as interpretation, research, duplicate detection, proposal development, scoring, and routing recommendations.

This is a product-direction proposal. I have not started implementing it because the underlying object and protocol shape should be discussed before code is written.

## Problem

Traditional project-management systems generally begin after someone has already decided that work should exist.

They are effective at managing:

- Tasks
- Owners
- Milestones
- Dependencies
- Reviews
- Delivery
- Completion

Important work happens before that point:

- Someone notices a problem
- An incomplete solution is proposed
- Related ideas are discovered
- The appropriate team is identified
- Evidence and counterevidence are gathered
- Assumptions and risks are examined
- Someone decides whether the idea deserves resources

Ideas rarely arrive as finished tickets. They may begin as a sentence in a conversation, a dictated stream of thought, a screenshot, a recurring customer concern, or several overlapping suggestions from different people.

Today, someone must usually choose between:

1. Interrupting their thinking to manually organize and file the idea
2. Leaving it in conversation and hoping someone returns to it

The first option creates administrative friction and premature tasks. The second loses potentially valuable ideas.

Even when the idea is copied into a tracker, it often becomes disconnected from:

- Its original context
- The people who contributed
- Related discussions
- Evidence and assumptions
- The decision that authorized or rejected it
- The work that followed
- The eventual outcome

This proposal would extend project management upstream so the managed lifecycle begins with the idea rather than the first approved task.

> Traditional project management helps a team execute a chosen idea. An Idea File helps an organization understand, develop, and choose the idea in the first place.

## Proposed Buzz-owned foundation

### 1. A first-class Idea File

An Idea File would represent a possibility that has not yet become authorized work.

At minimum, it could support:

- Stable identity
- Title and summary
- Original contributor
- Source message or thread
- Owning channel or team
- Visibility and permissions
- Lifecycle state
- Contributors
- Related records
- Human decision
- Update history
- Resulting execution work
- Final outcome or close reason

It should not require a Git repository.

The same object should work for product, engineering, marketing, operations, finance, research, community work, and other disciplines.

### 2. Creation from a conversation

A user could create an Idea File from an existing message or thread.

A minimal flow might be:

1. Select **Create Idea**
2. Review or enter a title and summary
3. Choose where the Idea File should initially live
4. Confirm creation

An agent could assist with the title and summary, but creating the Idea File should remain explicit unless a workspace deliberately configures another policy.

Creating an Idea File must not automatically:

- Authorize implementation
- Assign substantial work
- Spend resources
- Start multiple agents
- Notify unrelated teams
- Create an execution project

It preserves a possibility. It does not create a commitment.

### 3. Durable source provenance

The Idea File should remain linked to the message or thread that produced it.

Authorized users should be able to navigate in both directions:

```text
Source conversation → Idea File
Idea File → Source conversation
```

If the idea later becomes a project, the project should retain a durable relationship to the Idea File.

This would allow Buzz to answer questions such as:

- Where did this project originate?
- What did the original contributor mean?
- Which discussions shaped it?
- Why was it approved?
- Which assumptions changed?
- Did the completed work achieve the intended outcome?

### 4. Lifecycle and human decisions

Buzz could support a small pre-project lifecycle such as:

```text
Captured
Triage
Developing
Decision
Closed
```

These states describe the maturity of the idea.

They should remain separate from the decision made about it.

A decision record could support outcomes such as:

- Approve
- Approve a bounded proof
- Defer
- Reject
- Merge with existing work
- Request more information

The durable record should identify:

- Who made the decision
- When it was made
- The rationale
- Conditions or limits
- The resulting work

An agent recommendation must remain visibly different from human approval.

### 5. Relationships

Idea Files should be able to reference:

- Source messages or threads
- Related ideas
- Duplicate or overlapping ideas
- Parent or child ideas
- Existing issues or projects
- Blocking or blocked work
- Resulting experiments
- Resulting projects or tasks
- Final outcomes

This would allow people and agents to consolidate overlapping ideas without losing the original contributions.

Within the same visibility boundary, there should be one canonical Idea File rather than several copies that can drift.

### 6. Permission-aware routing and collaboration

The routing intelligence could come from a human, agent, or workflow. Buzz should own the permission checks and durable state change.

A route could record:

- Primary destination channel or team
- Collaborating teams
- Current owner
- Decision owner
- Contributors
- Routing history
- Who confirmed the route
- What information was shared

Cross-channel routing must respect visibility boundaries.

A private source conversation should not automatically expose its original wording, nearby messages, attachments, or restricted context.

Where permissions differ, Buzz may need to support:

- A sanitized destination-facing record
- A restricted provenance relationship
- Permission-aware navigation
- A clear record of what was shared and by whom

These protections should be enforced by the platform rather than relying only on agent instructions.

An Idea File should also support one primary owning team and additional collaborators without creating separate competing copies.

### 7. Channel-native Ideas view

Eligible channels could expose an **Ideas** view containing:

- Captured ideas
- Ideas in triage
- Ideas being developed
- Ideas awaiting decisions
- Recently approved ideas
- Deferred or rejected ideas
- Related or duplicate candidates

Selecting an Idea File could show:

- Original source
- Current summary
- Contributors
- Owning and collaborating teams
- Related records
- Linked Canvas
- Agent recommendation
- Human decision
- Resulting work
- Current outcome

Routine structured activity should update this view quietly rather than flooding chat.

Chat should surface events requiring attention, such as a decision request, invitation to contribute, meaningful blocker, completed proof, or material change to approved work.

### 8. Linked Canvas

An Idea File may need both compact operational state and a longer evolving narrative.

A linked Canvas could contain:

- Problem statement
- Proposed concept
- Evidence and counterevidence
- Assumptions
- Alternatives
- Risks
- Dependencies
- Research notes
- Proof plan
- Proposed implementation

Structured signed state could retain:

- Lifecycle
- Ownership
- Permissions
- Relationships
- Recommendation
- Human decision
- Resulting work

This would avoid treating a Canvas alone as the complete work object while still using it for the parts that benefit from a living document.

### 9. Promotion into execution

When an authorized human approves an idea, Buzz should allow it to create or link to execution work.

Possible destinations could include:

- NIP-34 issue
- Experiment
- Project
- Task
- RFC
- Agent job
- External tracker object through an adapter

The execution object should retain a durable relationship to the Idea File.

```text
Idea File
├── source conversation
├── development record
├── human decision
└── resulting work
├── tasks and agent jobs
└── outcome
```

The Idea File should remain available after promotion rather than being replaced.

### 10. Agent and CLI access

The same core operations should eventually be available through `buzz-cli` so humans, agents, and workflows operate on the same native state.

Potential operations include:

- Create and read an Idea File
- Update permitted metadata
- Link a source message
- Add a relationship
- Propose or perform an authorized route
- Add collaborators
- Link a Canvas
- Add a recommendation
- Request and record a human decision
- Query ideas by channel, owner, or lifecycle
- Link resulting execution work
- Record an outcome

Buzz should enforce identity, permissions, and valid transitions.

Being able to invoke an operation should not automatically grant authority to make a consequential decision.

## What configurable agents would provide

Once the native foundation exists, individual workspaces could configure agents to:

- Interpret unstructured submissions
- Research ideas
- Find related discussions
- Detect possible duplicates
- Consolidate overlapping contributions
- Suggest teams and collaborators
- Draft polished proposals
- Estimate value, effort, cost, and risk
- Recommend bounded proofs
- Recommend whether to approve, prove, defer, reject, or merge

These behaviors should remain configurable rather than being prescribed by this proposal.

## Example

A user writes:

> We keep giving administrators and regular members the same onboarding flow. What if onboarding first asked what someone is trying to accomplish and built the setup path around that?

The user selects **Create Idea**.

Buzz creates an Idea File linked to the original message.

A configured agent may later:

- Clarify the problem
- Find related discussions
- Add research to the linked Canvas
- Suggest Product as the primary team
- Suggest Engineering and Customer Experience as collaborators
- Draft a bounded experiment
- Recommend that the file move to Decision

A product lead reviews the Idea File and approves only the experiment.

Buzz links the experiment to the Idea File while preserving the complete lineage back to the original conversation and human decision.

If the experiment succeeds, it may produce a larger project. If it fails, the result and lessons remain attached to the original idea.

## Relationship to traditional project management

This proposal does not replace traditional project management.

Traditional project management begins once work is sufficiently defined and authorized.

The Idea File extends that lifecycle upstream and preserves continuity afterward.

```text
Raw idea
↓
Idea development
↓
Human authorization
↓
Project planning
↓
Execution
↓
Completion and outcome
```

A conventional backlog stores possible work.

An Idea File helps transform an undeveloped thought into something people can evaluate responsibly.

Once approved, familiar project-management concepts still apply, including owners, tasks, milestones, dependencies, boards, reviews, and completion criteria.

The improvement is that the managed record begins with the original idea rather than the first task.

## Smallest useful first slice

A possible initial slice could include:

- Create an Idea File from a message
- Stable source-message provenance
- Title and summary
- Owning channel and permissions
- A minimal idea-stage lifecycle
- Ideas list and detail view
- Linked Canvas
- Related-item links
- Human decision record
- Link an approved idea to an existing execution object
- Matching read and write operations through `buzz-cli`

This is offered as a starting point for discussion, not a fixed implementation plan.

## Non-goals

This proposal is not asking the first implementation to include:

- Automatic research
- Background idea development
- Automatic routing
- A prescribed scoring algorithm
- A Decision Matrix
- Automatic task creation
- Cross-functional orchestration
- A complete project-management suite
- A mandatory external tracker
- A particular model provider
- A hard-coded agent persona
- Drag-and-drop
- Fixed protocol identifiers proposed in advance

Those capabilities could later be developed through configurable agents, workflows, integrations, and additional native views.

## Related work

- #2934 proposes a Board for existing NIP-34 repository issues.
- #2647 proposes moving engineering work from Buzz into Linear with approval gates.
- #2990 concerns revision of published NIP-34 issues.

Those efforts may provide useful foundations, but they do not provide a generic pre-project object that can mature into work across code and non-code disciplines.

## Questions for maintainers

1. Is a first-class pre-project Idea File aligned with Buzz’s product direction?
2. Should it be a dedicated root event, a state layer over existing roots, or a combination?
3. Could a Canvas hold the living narrative while structured events hold lifecycle, permissions, relationships, and decisions?
4. What is the smallest independently useful creation, viewing, decision, and promotion flow?
5. Which operations should be exposed through `buzz-cli` from the first implementation?
6. Which existing project, Canvas, workflow, or approval primitives should this extend rather than duplicate?

The proposal identifies buzz-cli, NIP-34 issues, and linked Canvas as integration points but names no source files or tests. Start by mapping the existing Buzz object and protocol entry points alongside buzz-cli, then agree on the smallest foundation and its acceptance checks before implementation.

Written by the indexing model from the issue text.