Skip to content

TODO.md

Latest commit

 

History

History
28 lines (18 loc) · 4.79 KB

TODO.md

File metadata and controls

28 lines (18 loc) · 4.79 KB
Raw

TODO

Current Priority

  1. Sweep upgrade tool. Automate the manual cross-project upgrade/smoke sweep used for Riftbound, SocratexPipeline, Socratex-Business-Dogfood, and future child projects. Target a Python-first orchestration tool with OS-agnostic path handling, explicit project list/config input, per-project update/smoke phases, clean status checks, and a concise summary of pass/fail/drift. Value: high on every pipeline update; cost target: one focused evening.

  2. Python parity for audit_docs.py and check_pipeline_feature_contracts.py. Port or wrap the two highest-use pipeline smoke scripts with Python implementations so the core audit/feature-contract checks work with Python-only tooling as the primary runtime. Remove legacy shell wrappers and keep the portable Python implementation OS-agnostic and reusable by CI, child projects, and non-Windows hosts.

  3. Document-native tier checker backend. Make knowledge_tier_check and related tier tooling work from source documents directly, without requiring compiled SQLite. Treat document files plus DOCS.json as the source of truth; allow tier metadata in document metadata or an explicit DOCS.json override. Add backend selection such as documents, knowledge_files, sqlite, and auto, where auto uses SQLite only when it is current and declared, falls back to knowledge_files when appropriate, and otherwise scans documents directly. In SCRIPTS.json, make this explicit as a runtime contract: tier checks require compiled knowledge only when the SQLite backend is selected; document-native checks should remain available in projects without compiled SQLite.

  4. Canonical JSON document format expansion. Make index/content/metadata the preferred format for every repository JSON document that can reasonably be a human/AI-readable source document. Exclude runtime/game data such as game configs, saves, logs, generated runtime artifacts, and other files whose shape is owned by an engine or external protocol. First pass: classify every JSON file as canonical doc, migration candidate, domain/runtime exception, generated artifact, template, eval/result, or external-schema file. Then migrate safe candidates and add audit enforcement so every JSON file has either the canonical shape or an explicit allowed exception.

  5. Godot AI-readability sweeps, grouped by ownership area. Do not run one huge sweep. Split into focused passes such as application/session flow, runtime state and diagnostics, player/movement/combat, UI/HUD, content/data loading, and tooling/editor scripts. Each pass should identify major .gd systems that need clearer ownership, naming, boundaries, diagnostics, or a short AI_CONTRACT header.

  6. Godot comment-discipline sweeps, grouped after the AI-readability passes. For each Godot ownership area, keep comments that explain constraints, invariants, engine quirks, diagnostics, or warnings. Remove or replace narrative comments that merely restate code with clearer names, smaller methods, or explicit contracts.

  7. CI / quality gate publishing. After the JSON and Godot readability/comment passes, make the local run_quality_gate contract easy to publish into the selected CI or release workflow without committing provider-specific CI files before a provider is chosen.

Side Backlog

  • Task-specific research formalization flow: improve the pipeline so broad philosophy is converted into concrete task plans through contextual research instead of by stuffing every possible implementation-specific rule into always-loaded directives. The target code-touch flow is always-on: if a research-backed implementation plan already exists for the touched scope, execute it; if it does not exist, observe the task shape, load compact philosophy and project context, research known approaches/archetypes for this task/profile (for example AAA-style traversal, business bulk data, state management, security, migration strategy), share concise findings and tradeoffs, ask targeted scale/load/architecture questions when future pressure is unclear, formalize the plan with research conclusions, then execute or leave the plan ready for the next pass. This should prevent framing-inheritance failures where the agent inherits the user's symptom framing, such as "FPS drops, optimize like AAA", instead of noticing that the generic philosophy requires researching the structural model first. Preserve generic directives like "borrowed before invented", "better version now", and "avoid future refactor debt" while avoiding core directives that enumerate every domain-specific tactic such as physics indexing, ORM batching, or state-management details. Add an overengineering check: if research-driven better-version work becomes large or speculative, ask before expanding scope. This is a possible future pipeline feature, not an immediate always-loaded rule.