docs: codify SDD development process (issue #390)#392
Conversation
Adding .gitkeep for PR creation (default mode). This file will be removed when the task is complete. Issue: ProverCoderAI#390
|
Warning Review limit reached
More reviews will be available in 53 minutes and 58 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add docs/process.md describing the end-to-end Spec-Driven Development cycle from issue ProverCoderAI#390: clone --mcp-playwright, /plan with clarifying questions + Deep Research, Story with Prove (verifiable invariants), plan-to-git PR persistence, development via ToDos/subagents with Playwright MCP, CI and invariant verification. Incorporate the issue's follow-up requirements into AGENTS.md/CLAUDE.md: mandatory proof-of-fix on bug fixes and a ban on code/meaning duplication. Link the process doc from README. Closes ProverCoderAI#390
konard
changed the title
Working session summaryDone. PR #392 is ready for review with green CI. SummaryIssue #390 ("Как должна проходить разработка?") asks how development should proceed and, in its comments, requests that the paradigm be structured so work is provable. It's a process/vision issue — most runtime pieces already exist ( Changes (docs-only):
Verification: All 18 real CI checks pass (Build, Test, Types, Lint, Lint Effect-TS, full E2E matrix, cross-OS Final build, Snapshot). The single non-passing check is CodeRabbit reporting "Insufficient review credits" — an external billing condition, not a code failure. PR is mergeable. PR: #392 One note for you: this issue was open-ended ("how should development proceed"), so I interpreted the deliverable as canonical documentation of the workflow rather than new runtime tooling. If you'd instead like a concrete feature (e.g. a This summary was automatically extracted from the AI working session output. |
🤖 Solution Draft LogThis log file contains the complete execution trace of the AI solution draft process. 💰 Cost: $1.688603📊 Context and tokens usage:
Total: (3.0K new + 87.8K cache writes + 1.4M cache reads) input tokens, 16.8K output tokens, $1.688603 cost 🤖 Models used:
📎 Log file uploaded as Gist (1035KB)Now working session is ended, feel free to review and add any feedback on the solution draft. |
1 participant
Summary
Issue #390 («Как должна проходить разработка?») describes the intended
end-to-end development paradigm for
docker-git. This PR codifies thatparadigm as canonical documentation so the workflow becomes verifiable and
repeatable rather than tribal knowledge.
What changed
docs/process.md— new doc describing the full SDD (Spec-DrivenDevelopment) cycle, mapping each step to existing tooling:
clone --mcp-playwrightto provision an isolated env;/plan→ clarifying questions + Deep Research → Story ending with aProve block of verifiable invariants;
plan-to-git(already wiredin generated envs by feat(shell): sync agent plans to pull requests #371);
AGENTS.md/CLAUDE.md— added the issue's follow-up requirements tothe existing PROOF-obligations section:
the test that failed before and passes after);
code; one unit of meaning → one definition site).
README.md— links the new process doc..gitkeep.Why documentation
The issue and its comments ask "how should development proceed" and "how the
paradigm should be structured" — i.e. they request a defined, provable process.
Most of the runtime pieces already exist (
--mcp-playwright,--auto,plan-to-git, the formal-proof philosophy inAGENTS.md/CLAUDE.md); the gapwas a single canonical description tying them into one verifiable loop and the
two newly-stated requirements (proof-of-fix, anti-duplication).
Verification
Docs-only change.
docs/process.mdlinks resolve to existing files(
AGENTS.md,CLAUDE.md,README.md) and the README link points to the newdoc. No package code touched, so no changeset/version bump.
Closes #390