feat(pm): project-onboarding states the profile's decided home - #60
Merged
Merged
Conversation
Asana 1217123036545807, unblocked by Decision 1216550765662503: the Project Profile's canonical home is a Google Drive doc plus a pinned Asana resource task linking it. Onboarding states the home at the point of asking (override allowed for projects that keep it elsewhere) and prints 'Profile lives at:' on completion so downstream skills and tomorrow's session find it. Sweeps the open-decision phrasing from estimation, meeting-decisions, story-skill-generator, user-story, brainstorm, and qa test-suite. pm 0.24.0, qa 0.10.0. Asana: 1217123036545807
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 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 |
ravi-solanki-31
added a commit
that referenced
this pull request
Aug 21, 2026
Rebased onto development, which had landed PR #60 implementing the other answer to the same decision — a Drive doc plus a pinned Asana resource task. The eight overlapping files now carry the Asana-task home; PR #60's contract suite is kept and re-aimed rather than replaced, since its shape was right and only its assertions pointed the other way. Also kept from #60: the `Profile lives at:` completion line, which does the same job as this branch's `Profile:` line and reads better. 26 checks, mutation-verified — inverting the no-override rule and the read-all-subtasks rule each turn a check red. Adds coverage #60 did not have: core owning the convention, the project never being inferred from a source, the exact no-project stop message, and the delta record. Versions bumped above development: core 0.17.0, pm 0.25.0, qa 0.11.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ravi-solanki-31
added a commit
that referenced
this pull request
Sep 8, 2026
* feat: fix the Project Profile home to one Asana task per project The profile's canonical home was an open decision, so onboarding asked the PM where to put it and every consumer asked where to find it. Nobody recorded the answer anywhere durable, so a later run could not locate a profile that already existed — and skills did not stop when they could not find one. estimation ran without profile-driven widening; recipes and ui-creation fell back to house defaults and ignored overrides that existed. Both looked like successful runs. The profile now lives in Asana as `Project Profile - <project name>` in the project it describes, one subtask per section. The convention is fixed in raftkit-core/workflow-constants, so every consumer resolves it the same way and none of them ask. - core: the convention, plus how to find a project's profile (read all subtasks; never look one up by section name, since a thin profile has fewer sections) - pm: onboarding writes the parent + subtasks, takes the Asana project as an input and never infers it from a source's contents, resolves a rough project name against Asana, re-targets without re-ingesting when the PM corrects it, and treats a write timeout as possibly-succeeded rather than blind-retrying - pm/qa/dev: estimation, meeting-decisions, story-skill-generator, user-story, brainstorm, test-suite, recipes, ui-creation and docs all resolve by convention instead of asking - facts render as lists, never tables — Asana renders no table in a task description; the draft is shown in the shape it will be written Verified end to end against a scratch Asana project: parent, five subtasks, no tables, conflicts as nested lists, read-back clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(pm): record every profile delta as a comment on the parent task Asana keeps no history of a description edit — an overwritten subtask leaves no trace of what it said before, and the task's story feed stays silent. Verified on a live delta: five subtasks were rewritten and Asana logged nothing at all, so the only record was the terminal scrollback the PM had already approved. Onboarding and meeting-decisions now post one comment on the parent task after a delta's writes land: source added, subtasks rewritten, then changed / new / conflicts added / now-confirmed. One comment per run, never one per subtask. It records what changed rather than the new content, so it grows with the size of the change and not the size of the profile. That makes it an audit trail, not a backup — restoring an earlier value still means going back to its source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(pm): user-story states when it is not grounding a story in the profile The wording said "the Project Profile and/or the project's own sources", which let a run ground entirely in other sources and never mention that a profile existed. Observed on a live run: it read workflow-constants to learn how profiles are found, then listed five repo files as its sources and never fetched the profile task that was sitting in the project. That is the same silent omission this branch removed from estimation — a profile is there, it is not used, and nothing says so. Using the profile is now the default, and not using it is a stated decision with a reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test: point the profile-home contract suite at the Asana-task home Rebased onto development, which had landed PR #60 implementing the other answer to the same decision — a Drive doc plus a pinned Asana resource task. The eight overlapping files now carry the Asana-task home; PR #60's contract suite is kept and re-aimed rather than replaced, since its shape was right and only its assertions pointed the other way. Also kept from #60: the `Profile lives at:` completion line, which does the same job as this branch's `Profile:` line and reads better. 26 checks, mutation-verified — inverting the no-override rule and the read-all-subtasks rule each turn a check red. Adds coverage #60 did not have: core owning the convention, the project never being inferred from a source, the exact no-project stop message, and the delta record. Versions bumped above development: core 0.17.0, pm 0.25.0, qa 0.11.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(pm): make user-story's frontmatter parse again Its description carried "amend mode: a diff-first additive edit". A colon followed by a space ends a plain YAML scalar, so the whole frontmatter failed to parse and the skill loaded with empty metadata — name, description and the user-invocable flag all silently dropped. Pre-existing on development; it surfaces here because CI validates the skills a PR touches. Colon swapped for a dash. Scanned every other SKILL.md in the marketplace — no other frontmatter fails to parse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: restore the plugin descriptions the rebase duplicated Resolving the manifest conflicts left raftkit-pm with two "description" keys — development's, naming the deprecation sweep, and this branch's older one. JSON takes the last, so the stale description won and drifted from marketplace.json. All three manifests are now development's file verbatim with only the version line changed, which is the only thing this branch should be touching in them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(pm): make a written profile readable, not just correct Review feedback on the generated profile: too much information packed into each subtask, and subtask names that do not say what is inside them. Both are fair — the test run put ~45 facts into "Business rules and limits" under seven internal headings, several single facts ran past 80 words, and the tag legend was repeated at the top of all five subtasks. Four rules, so a profile is written to be read: - A fact is one sentence, inside the house 25-word limit. A fact needing three clauses is three facts, each carrying its own tag — an 80-word bullet hides which part is confirmed and which is not. - One subject per section. The four named sections are a starting point, not a ceiling: past about 15 facts a section splits by subject, and headings appearing inside a section mean those headings were the sections. - Subtask names carry a plain-English gloss — "Glossary — what the project's terms mean" — so someone opening a profile cold knows what is in it. - Each subtask opens with one line saying what it holds and how many facts. The tag legend sits on the parent once instead of five times. 7 new contract checks, mutation-verified. pm 0.26.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(core): never HTML-escape an Asana task name The regenerated profile came back with four subtasks called "Architecture & delivery loop" and the like. The escape rule said to escape &, < and > in text content without saying where it applies, so it was applied to task names as well as HTML bodies. A name is plain text on the way in, so nothing decodes it and the reader sees the entity. Rule now says escaping is for an HTML body only. The four subtasks in the test profile were renamed by hand. 1 contract check, mutation-verified. core 0.18.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(pm): space the profile section-heading example Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Asana 1217123036545807, unblocked by Decision 1216550765662503: the Project Profile's canonical home is a Google Drive doc plus a pinned Asana resource task linking it. Onboarding states the home at the point of asking (override allowed for projects that keep it elsewhere) and prints 'Profile lives at:' on completion. Sweeps the open-decision phrasing from estimation, meeting-decisions, story-skill-generator, user-story, brainstorm, and qa test-suite. Suite: tests/profile-home.test.sh — 15 checks, mutation-verified. pm 0.24.0, qa 0.10.0.