@goodtek/vibeops 0.7.22 → 1.1.1

package/templates/docs/logs/README.md

@@ -1,38 +0,0 @@
-# Daily Logs
-
-This directory follows a **one-file-per-day** policy.
-
-- Filename: `YYYY-MM-DD.md` (local date).
-- Create the file on the day's first change. Additional changes the same day append entries to the same file.
-- Logs are **fact-first**: decision summary, changed files, verification result, next work.
-
-## Entry template
-
-```
-## YYYY-MM-DD · TASK-NNN <short title>
-
-### Decision summary
-
-- ...
-
-### Changed files
-
-- new: ...
-- update: ...
-
-### Verification
-
-| Command | Result |
-| --- | --- |
-| `...` | ... |
-
-### Next work
-
-- TASK-NNN — ...
-```
-
-## Non-goals
-
-- Chitchat, opinions, self-praise.
-- Copy-pasted TASK bodies.
-- Secret values that should not be committed.

package/templates/docs/project/00-overview.md

@@ -1,27 +0,0 @@
-# 00 — Overview
-
-> This document is the slot that `vibeops plan` (via the `planner` agent) fills in. Keep the section headers below and leave the bodies empty.
-
-## One-line definition
-
-<!-- One sentence describing what this project is — who it is for and what the tool/service does. -->
-
-## Problem to solve
-
-<!-- 3 to 5 bullets. Stay fact-based about current pain points. -->
-
-## Example usage
-
-<!-- A 6-to-10-line scenario showing how a single hypothetical user flows through the product. -->
-
-## Core roles
-
-<!-- 4 to 8 things this product "does", one per line. Each line starts with a verb. -->
-
-## Vocabulary
-
-<!-- 5 to 10 terms that mean something specific in this project. Disambiguate synonyms. -->
-
-## Non-goals (out of scope, forever)
-
-<!-- Things this project intentionally does not do. Different from "out of MVP scope" — that lives in 02-mvp-scope.md. -->

package/templates/docs/project/01-requirements.md

@@ -1,30 +0,0 @@
-# 01 — Requirements
-
-> Filled in by the `planner` agent.
-
-## Functional requirements
-
-<!--
-Numbered. Each line reads "the system does …".
-F-001. Users can ...
-F-002. The system ...
--->
-
-## Non-functional requirements
-
-<!--
-Performance / reliability / security / operations / compatibility.
-NF-001. No command may corrupt user data ...
--->
-
-## Users / stakeholders
-
-<!-- Who uses the product, who cares about it. By role. -->
-
-## Constraints
-
-<!-- Technical, schedule, budget, regulatory — anything imposed from outside. -->
-
-## Assumptions
-
-<!-- The "let's assume this is true" list. Items that would be risky if they break. -->

package/templates/docs/project/02-mvp-scope.md

@@ -1,36 +0,0 @@
-# 02 — MVP Scope
-
-> Filled in by the `planner` agent. Keep it small.
-
-## MVP in one sentence
-
-<!-- A single line: "Within two weeks, who can do what." -->
-
-## In scope
-
-<!--
-The 5 to 10 capabilities the MVP must have.
-- IN: sign-up and single sign-on
-- IN: ...
--->
-
-## Intentionally out for MVP
-
-<!--
-Things that may ship later but not in the MVP.
-- OUT: multiple workspaces
-- OUT: payment UI
-The clearer this is, the smaller the backlog gets.
--->
-
-## Definition of done
-
-<!--
-- Which scenarios run end-to-end.
-- Which data flows are preserved.
-- Which error situations are tolerated.
--->
-
-## How to validate
-
-<!-- How a real person confirms "the MVP is ready". One demo scenario. -->

package/templates/docs/project/03-architecture.md

@@ -1,34 +0,0 @@
-# 03 — Architecture
-
-> Filled in by the `architect` agent.
-
-## Big picture
-
-<!--
-Use an ASCII diagram to draw the "inside / outside the system" boundary.
-Flows like user → frontend → backend → DB / external services.
--->
-
-## Components
-
-<!--
-| Name        | Responsibility           | Inputs        | Outputs       |
-| ----------- | ------------------------ | ------------- | ------------- |
-| component-a | ...                      | ...           | ...           |
--->
-
-## Data model
-
-<!-- The 3 to 7 core entities and how they relate. Field-level detail belongs to a separate TASK. -->
-
-## Data flow
-
-<!-- The call sequence for the 1 to 2 most common user scenarios. -->
-
-## External boundaries
-
-<!-- Which external services / APIs we talk to. Auth method, public or private. -->
-
-## Non-deterministic / failure paths
-
-<!-- High-level behavior under network failures, concurrency, data loss. -->

package/templates/docs/project/04-tech-stack.md

@@ -1,29 +0,0 @@
-# 04 — Tech Stack
-
-> Filled in by the `architect` agent. Add a one-line "why" to each choice.
-
-## Runtime / language
-
-<!-- Node.js / Python / Go, etc. Version. The reason behind the choice. -->
-
-## Frameworks / libraries
-
-<!--
-| Area    | Choice             | Why                                            |
-| ------- | ------------------ | ---------------------------------------------- |
-| Server  | ...                | ...                                            |
-| ORM     | ...                | ...                                            |
-| Tests   | vitest             | TS-friendly, fast                              |
--->
-
-## Infrastructure
-
-<!-- Where the system runs, how it is deployed (high level). Detailed commands live in 09-deployment.md. -->
-
-## Package manager / build
-
-<!-- pnpm / npm / yarn, tsc / esbuild / vite, etc. Whether there is a single entry point. -->
-
-## Explicit non-adoptions
-
-<!-- Things we deliberately do not use, and why. -->

package/templates/docs/project/05-current-state.md

@@ -1,35 +0,0 @@
-# 05 — Current State
-
-> Record **facts only**. The `docs` agent refreshes this document after each implementation.
-
-## Stage
-
-- **Current stage**: bootstrap complete. Planning and implementation have not started yet.
-- No code (`src/`, `package.json`, …) exists yet.
-
-## What is in place
-
-| Item              | Location                              | Notes                       |
-| ----------------- | ------------------------------------- | --------------------------- |
-| Operating guide   | `AGENTS.md`, `.cursor/rules/*`        | Installed by VibeOps        |
-| Agent definitions | `.vibeops/agents/*`                   | 8 agents                    |
-| Project docs      | `docs/project/00 ~ 09`                | Empty (waiting for plan)    |
-| TASK folder       | `docs/tasks/`                         | Empty (waiting for generate) |
-| Logs folder       | `docs/logs/`                          | Empty                       |
-
-## What is missing
-
-- The actual bodies of `docs/project/*` (planner / architect will fill these in).
-- `docs/tasks/TASK-001-*.md` (`task generate`).
-- Any code at all.
-- Notion connection (run `vibeops notion init` if desired).
-
-## Next TASK
-
-**The backlog is empty.** Run `vibeops plan --idea "<your idea>"` to fill in `docs/project/{00,01,02,07}`; the first TASK candidates fall out of that.
-
-## Working rules (short summary)
-
-- Implement **one TASK at a time**.
-- Every mutating command should support `--dry-run` when possible.
-- After implementation, update this document, the TASK file, and `docs/logs/YYYY-MM-DD.md` together.

package/templates/docs/project/06-decisions.md

@@ -1,20 +0,0 @@
-# 06 — Decisions
-
-Decisions that have already been made. A conflicting proposal changes them only after a separate TASK reopens the discussion.
-
-## D-001 · Source of truth is Git `docs/`
-
-Chat is not trusted. When docs and chat disagree, fix the docs first, then implement.
-
-## D-002 · One TASK at a time
-
-Large refactors do not happen without a dedicated TASK.
-
-## D-003 · Notion is the human dashboard (metadata only)
-
-No body sync. No realtime.
-
-<!--
-Add later decisions as `D-NNN · one-line summary`.
-Keep each entry short — one paragraph that covers "why" and "result".
--->

package/templates/docs/project/07-backlog.md

@@ -1,23 +0,0 @@
-# 07 — Backlog
-
-TASK order. Work top to bottom. Do not skip to the next item before the current TASK is done.
-
-> Slot to be filled by the `planner` agent.
-
-## MVP 1
-
-| ID       | Title                               | Status  |
-| -------- | ----------------------------------- | ------- |
-| TASK-001 | <first TASK title>                  | planned |
-
-## MVP 2 (later)
-
-<!-- Slot. -->
-
-## Later (out of MVP, but live candidates)
-
-<!-- Items to revisit after MVP. Do not turn them into TASKs right away. -->
-
-## Non-goals
-
-Follow the "Non-goals" section in `docs/project/00-overview.md`. The backlog only grows inside those bounds.

package/templates/docs/project/08-env.md

@@ -1,29 +0,0 @@
-# 08 — Environment
-
-Environment variables used by this project and what they mean.
-
-## Local development
-
-Copy `.vibeops.env.example` to `.vibeops.env` and fill in the values. Never commit `.vibeops.env` — it is listed in `.gitignore`.
-
-| Variable        | Purpose                                                          | Required        |
-| --------------- | ---------------------------------------------------------------- | --------------- |
-| `NOTION_TOKEN`  | Notion internal integration secret (the only secret VibeOps reads) | If using Notion |
-
-`NOTION_TOKEN` is the only secret VibeOps reads from the environment. Notion **Projects / Tasks DB target IDs** are not environment variables — they live in `.vibeops.json` as `notion.projectsTargetId` / `notion.tasksTargetId`, and `vibeops notion init` writes them. GitHub auth is owned by `gh auth`, so there is no need to put `GITHUB_TOKEN` here.
-
-> The legacy `NOTION_API_KEY` / `NOTION_PROJECT_DB` / `NOTION_TASK_DB` environment variables are no longer used. VibeOps ignores them if they remain in an existing `.vibeops.env`. It is safe to remove them by hand.
-
-<!--
-Add project-specific environment variables here once they exist.
-Examples: DATABASE_URL, OAUTH_CLIENT_ID, ...
--->
-
-## Staging / production
-
-<!-- Slot. -->
-
-## Secret management
-
-- `.vibeops.env` is a plain-text local file. Production secrets belong in a real secret manager.
-- No VibeOps command prints secret values to stdout in the clear (they are masked).

package/templates/docs/project/09-deployment.md

@@ -1,28 +0,0 @@
-# 09 — Deployment
-
-How the project is deployed and run.
-
-## Local run
-
-<!-- The single-command dev-server flow (e.g. `pnpm dev`). -->
-
-## Build
-
-<!-- Where build artifacts live and which command produces them. -->
-
-## Packaging / release
-
-<!--
-Steps per target environment.
-- npm publish?
-- Docker image?
-- Cloud (Vercel / Fly / AWS / GCP / ...) ?
--->
-
-## Environment separation
-
-<!-- Differences between dev / staging / prod. Same code with different env? Same image? -->
-
-## Rollback
-
-<!-- The standard rollback flow when a deployment goes wrong. -->

package/templates/docs/tasks/TASK-000-template.md

@@ -1,72 +0,0 @@
-# TASK-NNN · <one-line title>
-
-> This file is an example produced from VibeOps' `TASK-000-template.md`.
-> Real TASKs come from `vibeops plan` (TASK-mvp), `vibeops task add` (work-now slice), or your backlog process. Filenames follow `TASK-NNN-<slug>.md`.
-
-## Status
-
-planned
-
-## MVP Phase
-
-MVP 1 · <phase name>
-
-## Goal
-
-<2 to 4 sentences. What becomes possible when this TASK ships.>
-
-## Background
-
-<Why this is needed now. Which prior decisions / TASKs this builds on.>
-
-## Scope
-
-- <bullet 1>
-- <bullet 2>
-
-## Out of Scope
-
-- <explicit exclusion 1>
-- <explicit exclusion 2>
-
-## Acceptance Criteria
-
-1. <verifiable statement>
-2. <verifiable statement>
-
-## Files to Inspect First
-
-- <path 1>
-- <path 2>
-
-## Expected Files to Change
-
-- new: <path>
-- update: <path>
-
-## Risks
-
-- <risk 1 and mitigation>
-- <risk 2 and mitigation>
-
-## Test Plan
-
-- <command / case 1>
-- <command / case 2>
-
-## Rollback Plan
-
-- <how to roll back>
-
-## Implementation Plan
-
-1. <step 1>
-2. <step 2>
-
-## Result
-
-(not yet)
-
-## Test Result
-
-(not yet)