148 lines
3.3 KiB
Markdown
148 lines
3.3 KiB
Markdown
# Workplan
|
|
|
|
## Goal
|
|
|
|
Establish `tegwick-control` as the first working control repository for the broader personal, corporate, technical, and commercial project landscape.
|
|
|
|
## Phase 0 — Create the Repository
|
|
|
|
### Objective
|
|
|
|
Create the initial repo structure and seed the core documents.
|
|
|
|
### Tasks
|
|
|
|
- Create `tegwick-control` in the `tegwick` Gitea organization.
|
|
- Add `INTENT.md`.
|
|
- Add `SCOPE.md`.
|
|
- Add `PROJECT_LANDSCAPE.md`.
|
|
- Add `OPERATING_MODEL.md`.
|
|
- Add `WORKPLAN.md`.
|
|
- Add `TASKS.md`.
|
|
- Add `DECISIONS.md`.
|
|
- Add `AGENT_RULES.md`.
|
|
- Create `areas/`, `inbox/`, `agent-tasks/`, and `templates/`.
|
|
|
|
### Done When
|
|
|
|
The repository exists and provides a first usable overview of the project landscape.
|
|
|
|
---
|
|
|
|
## Phase 1 — Establish Area Cards
|
|
|
|
### Objective
|
|
|
|
Create one area card for each major organization/topic.
|
|
|
|
### Tasks
|
|
|
|
- Create `areas/private-life.md`.
|
|
- Create `areas/binky-company.md`.
|
|
- Create `areas/helix-forge.md`.
|
|
- Create `areas/coulomb.md`.
|
|
- Create `areas/sloppers.md`.
|
|
- Create `areas/whywhynot.md`.
|
|
- Create `areas/plenitude.md`.
|
|
|
|
### Done When
|
|
|
|
Each major topic has a clear purpose, activation level, current state, and next surface.
|
|
|
|
---
|
|
|
|
## Phase 2 — Stabilize Binky Visibility
|
|
|
|
### Objective
|
|
|
|
Make the company rescue situation explicit without trying to solve everything at once.
|
|
|
|
### Tasks
|
|
|
|
- List open legal/accounting/tax obligations.
|
|
- List known business model options.
|
|
- List urgent company survival risks.
|
|
- Identify the first accountant/tax-advisor reactivation step.
|
|
- Identify first revenue-oriented offer candidate.
|
|
|
|
### Done When
|
|
|
|
Binky has a clear critical path list and no longer exists only as diffuse pressure.
|
|
|
|
---
|
|
|
|
## Phase 3 — Define Helix as Production Path
|
|
|
|
### Objective
|
|
|
|
Clarify that serious product implementation should move through Helix rather than ad-hoc tooling.
|
|
|
|
### Tasks
|
|
|
|
- Document Helix's role as intent-to-product engine.
|
|
- Define how product ideas become implementation candidates.
|
|
- Define how agentic coding tasks should be prepared.
|
|
- Identify required repo templates and task formats.
|
|
|
|
### Done When
|
|
|
|
There is a clear path from idea to structured implementation task.
|
|
|
|
---
|
|
|
|
## Phase 4 — Plan Coulomb Migration
|
|
|
|
### Objective
|
|
|
|
Turn Coulomb from a Bubble.io timesink into a controlled migration target.
|
|
|
|
### Tasks
|
|
|
|
- Capture current Bubble.io functionality.
|
|
- Identify must-keep features.
|
|
- Identify obsolete/friction-heavy features.
|
|
- Define first Helix-based replacement slice.
|
|
- Define migration risks.
|
|
|
|
### Done When
|
|
|
|
Coulomb has a migration plan and no longer depends on open-ended Bubble evolution.
|
|
|
|
---
|
|
|
|
## Phase 5 — Incubate Market and Community Layers
|
|
|
|
### Objective
|
|
|
|
Keep WhyWhyNot, Sloppers, and Plenitude alive without letting them become premature obligations.
|
|
|
|
### Tasks
|
|
|
|
- Define WhyWhyNot prototype intake model.
|
|
- Define Sloppers/Zulip community hypothesis.
|
|
- Define Plenitude commercial offer categories.
|
|
- Mark all three as A1 Incubating unless explicitly activated.
|
|
|
|
### Done When
|
|
|
|
The market/community/store layer is visible but not stressful.
|
|
|
|
---
|
|
|
|
## Phase 6 — Establish Review Rhythm
|
|
|
|
### Objective
|
|
|
|
Create a light review cycle that supports progress without creating bureaucracy.
|
|
|
|
### Tasks
|
|
|
|
- Define daily capture habit.
|
|
- Define weekly review template.
|
|
- Define monthly landscape review.
|
|
- Define agent-assisted review prompts.
|
|
|
|
### Done When
|
|
|
|
There is a simple rhythm for keeping the system current.
|