Skip to content

README.md

Latest commit

 

History

History
73 lines (60 loc) · 3.61 KB

README.md

File metadata and controls

73 lines (60 loc) · 3.61 KB
Raw

Codegeist Task Guide

Repository-local task files preserve implementation detail that does not fit in a GitHub issue. They are working specifications and historical records, not a standalone public backlog.

Read CONTRIBUTING.md before starting implementation. Codegeist also uses the account-wide Code of Conduct, Security Policy, and Support Guide. The T010 account rollout is complete. Shared policy, CI, repository metadata, private reporting, and branch-protection settings are published and verified.

Statuses

  • open means the task still has unresolved scope or implementation work. It is not automatically ready for an external contributor.
  • in progress means implementation is actively underway.
  • solved, completed, implemented, and finalized are historical completion terms already used by this repository. They all mean the described work is not available as new work.
  • deferred means the work was intentionally postponed and needs a new readiness decision before implementation.
  • cancelled means the task is closed without implementation.
  • backlog records an idea that has not yet become an accepted implementation task.
  • Historical plans, research, and solve notes remain useful context even when a parent task still says open; inspect child statuses and current source before assuming any work remains.

New task files should use the smallest status vocabulary that accurately describes their state. Rewrite stale status text when work changes state rather than treating old task files as a list of ready issues.

Public Tracking

The public workflow is:

Codegeist Roadmap -> repository Issue -> repository task file -> branch -> PR -> merge
  • The Codegeist Roadmap is the cross-repository planning view.
  • Codegeist Issues own public discovery, discussion, priority, assignment, and status for this repository.
  • A local task file owns accepted implementation scope, acceptance criteria, file targets, non-goals, and verification.
  • Every issue marked ready for implementation should link its canonical task path.
  • Every publicly tracked task should replace pending issue creation with the full GitHub issue URL.
  • A pull request should link the issue and task, report verification, and close the issue when the implementation is complete. Update the task status in the same implementation unit when practical.

Ideas do not need a task and issue immediately. Create both when maintainers accept the work for implementation and need a durable contract. Do not mirror an entire task specification into an issue body, and do not advertise historical, deferred, or merely open task records as ready work.

Current Contributor Foundation Work

  • T010_build-shared-github-contributor-foundation/ is the finalized account-wide rollout tracked by codegeist-ai/codegeist#2. Shared policy and profile repositories, the Roadmap, source-repository pull request checks, licensed kit releases, metadata, private vulnerability reporting, branch protection, and the final community-profile audit are complete.

No contributor task is currently advertised as ready. New public tasks should be created only after maintainers accept concrete repository work, not to populate the Roadmap or meet an issue-count target.