@goodtek/vibeops 0.7.22 → 1.0.0

package/templates/.vibeops/workflows/rollback.md

@@ -1,45 +0,0 @@
-# Workflow · Rollback
-
-The standard "this TASK went wrong, let's undo it" flow.
-
-## 1. Diagnose first
-
-```bash
-vibeops task rollback TASK-NNN
-```
-
-The default is **guidance only**. It shows:
-
-- Current branch / dirty state.
-- Base branch / base commit / task branch as read from `.vibeops/state/tasks/TASK-NNN.json`.
-- Three possible strategies.
-
-## 2. Available strategies
-
-| Strategy          | Description                                                  | What you could lose                  |
-| ----------------- | ------------------------------------------------------------ | ------------------------------------ |
-| `branch-delete`   | Discard the task branch                                      | Every unmerged change on the branch  |
-| `reset-base`      | Hard-reset the current branch to the base commit              | Your current changes (stash first)   |
-| `revert-merge`    | If already merged, revert the merge commit                    | Adds a revert commit to history (OK) |
-
-## 3. Execute (destructive, `--confirm` required)
-
-```bash
-vibeops task rollback TASK-NNN --strategy branch-delete --confirm
-vibeops task rollback TASK-NNN --strategy reset-base --confirm
-vibeops task rollback TASK-NNN --strategy revert-merge --confirm
-```
-
-Combining `--dry-run` with `--confirm` prints the commands that would run without executing them.
-
-## 4. Things you never do
-
-- **`git push --force`**: never on shared branches. Even on your own task branch, do not run it unless the reason is unambiguous.
-- Automatic reflog cleanup.
-- Dropping stashes without explicit user consent.
-
-## 5. After rollback
-
-- Reset `docs/tasks/TASK-NNN-*.md` Status to `planned` or `blocked` and record the reason in Result.
-- Update `docs/project/05-current-state.md`.
-- Append a one-line entry to `docs/logs/YYYY-MM-DD.md`: "Rollback: TASK-NNN — reason".

package/templates/.vibeops/workflows/task-lifecycle.md

@@ -1,71 +0,0 @@
-# Workflow · Task Lifecycle
-
-A TASK from start to finish.
-
-## 0. Pick
-
-Run `vibeops status` to identify the next TASK. Typically run `in_progress` items before `planned` ones.
-
-## 1. Start
-
-```bash
-vibeops task start TASK-NNN
-```
-
-- A dirty working tree is refused unless changes are limited to governance docs (`docs/tasks/`, `docs/project/`, `docs/logs/`, `.vibeops/state/`); then `task start` warns and continues. Use `--allow-dirty` only when non-doc paths are dirty intentionally.
-- Records base branch / base commit / task branch in `.vibeops/state/tasks/TASK-NNN.json`.
-- Creates and checks out the `task/NNN-<slug>` branch.
-- Sets the TASK file's Status to `in_progress`.
-
-## 2. Prompt
-
-```bash
-vibeops task prompt TASK-NNN --agent builder
-```
-
-Paste the single markdown output directly into the Cursor chat. Cursor takes on the builder agent role.
-
-Other agents work the same way:
-- `--agent reviewer` — review the diff.
-- `--agent tester` — run the Test Plan.
-- `--agent docs` — update the three docs.
-
-## 3. Check
-
-```bash
-vibeops task check TASK-NNN
-```
-
-- Score Acceptance Criteria items with ✓ / ✗.
-- Match `Expected Files to Change` against actual changes.
-- Summarize current branch / dirty / commit count.
-
-## 4. Done
-
-```bash
-vibeops task done TASK-NNN
-```
-
-- Validates the TASK file's Status, Result, Test Result bodies.
-- Records `doneAt` in `.vibeops/state/tasks/TASK-NNN.json`.
-- Prints **merge guidance** (no automatic merge).
-
-A human merges:
-
-```bash
-git switch main
-git merge --ff-only task/NNN-<slug>
-git branch -d task/NNN-<slug>
-```
-
-## 5. (Optional) Notion sync
-
-```bash
-vibeops notion sync
-```
-
-Pushes TASK metadata (summary, status, priority, branch, docs path, result summary) to Notion.
-
-## When things go wrong: Rollback
-
-See [`rollback.md`](rollback.md).

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/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/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. -->