Forge Project Cleanup Ambiguities
Record of ambiguities encountered during Plans 1-4, per Spec §10.
| # | Affected area | Decision needed | Options considered | Recommended option | Resolution | Responsible owner | Status | Related todo item |
|---|---|---|---|---|---|---|---|---|
| A1 | Spec §2 / Migration mapping | Whether the migration mapping table in Forge_Project_Workflow.md (showing former Erik_Todo → todos replacement) constitutes an “active instructional reference” that must be removed | (1) Remove the mapping table entirely; (2) Keep the mapping table as historical reference context | Option (2) — The mapping table documents the migration for users transitioning from the old system and is clearly labeled as “Former behavior → Replacement behavior” | Kept as historical reference context — the table is not an instruction to use Erik_Todo; it documents the migration | erik@uvilo.com | Resolved | — |
| A2 | Spec §3 / WIP references in non-project files | Whether WIP references in Forge/Output/README.md and Project_Create/SKILL.md template table constitute “active WIP instructions” that must be removed | (1) Remove all WIP references everywhere; (2) Keep historical/test references that are not instructions | Option (1) — Even non-instructional WIP references can confuse users about whether WIP is still active | Removed stale WIP_Template.md row from Project_Create/SKILL.md template table; removed Output_WIP.md reference from Forge/Output/README.md | Agent (Plan 4 Task 1) | Resolved | — |
| A3 | Spec §7 / Run-cost evidence | Whether the project must have exact token/cost data to satisfy the run/cost evidence requirement | (1) Require exact data; (2) Accept explicit “unavailable” notation with available context | Option (2) — The platform does not currently expose exact token/cost data to agents; requiring it would block completion | Explicit “unavailable” notation with available context (convo IDs, dates, commands) is recorded in inventory and eval reports | erik@uvilo.com | Resolved | — |
| A4 | Spec §9 / Charter partial items | Whether ⚠️ Partial Charter alignment items that would require changing the lifecycle shape (Spec §8) should be corrected in this project | (1) Add stakeholder-impact, security, and privacy checkpoints to templates; (2) Document as known gaps with out-of-scope rationale | Option (2) — Spec §8 explicitly states “The cleanup does not add new phases or new work-product types”; adding checkpoints would change the lifecycle shape | Documented as known gaps with out-of-scope rationale in Charter alignment matrix; recommended as future improvements | erik@uvilo.com | Resolved | — |
| A5 | Spec §7 / Inngest schedule prompts | Whether stale Erik_Todo/WIP references in the uvilo-mono orchestrator schedules.ts task prompts are in scope for this cleanup | (1) Update the uvilo-mono code; (2) Record as out-of-scope and note separately | Option (2) — This project’s scope is the uvilo-os repo (Knowledge, Skills, Guides, Prompts, Templates); the orchestrator code is in uvilo-mono | Recorded in infrastructure inventory as a known issue; uvilo-mono orchestrator schedule prompts should be updated separately | erik@uvilo.com | Resolved | — |
| A6 | Spec §6 / Bot prompt version numbering | Whether the compliance audit in the Bot Prompt Inventory document (recording versions 12, 4, 3, 7) is sufficient evidence of prompt inspectability, or whether prompt-version artifacts must also be verified as accessible | (1) Accept inventory document as sufficient; (2) Verify prompt-version artifacts are accessible | Option (1) — Prompt-version artifacts were created in Plan 3; the inventory records the version numbers; full accessibility verification would require runtime checks outside this project’s scope | Inventory document accepted as sufficient evidence; prompt-version artifacts exist from Plan 3 | erik@uvilo.com | Resolved | — |
| A7 | Spec §12 / Default human gates | Whether the default human gates (Spec_Eval, Plan_Eval, Verify) should be written to existing project Phase files that lack human_gates frontmatter | (1) Write defaults to all existing Phase files; (2) Document the default and apply only to new projects | Option (2) — Modifying existing project Phase files could disrupt in-progress projects; the default is documented and the Runner applies it when the key is absent | Default documented in Spec §12 and project-runner prompt; applied only when human_gates key is absent from Phase file | erik@uvilo.com | Resolved | — |
| A8 | Spec §1 / Knowledge status values | Whether Forge_Agent_Architecture.md, Forge_Document_Structure.md, and Forge_Charter.md having approved status (not published) constitutes a compliance issue | (1) Change status to published; (2) Accept approved as sufficient for foundational documents | Option (2) — These are foundational/architectural documents that may follow a different publication workflow than user-facing guides; changing status without understanding the publication workflow could be incorrect | Accepted as-is; approved status is sufficient for foundational documents that are not user-facing guides | erik@uvilo.com | Resolved | — |
Summary
| Status | Count |
|---|---|
| Resolved | 8 |
| Pending | 0 |
All ambiguities have been resolved. No pending user decisions remain. No todo items needed for unresolved ambiguities.