Raised by a Product Hunt review: "not clear yet how it handles pair-programmed or heavily AI-assisted commits when it comes time to defend the work, would be good to know upfront if that gets flagged differently."
The policy answer is now in docs/faq.md: AI-assisted work is never flagged as lesser, the bundle carries bounded agent-involvement signals, and pair commits inherit git's one-author-per-commit model. But the review points at real product gaps beyond documentation:
1. Show the AI-involvement signals upfront (no schema change)
The bundle already carries ai_workflow (agent co-authorship counts, tool-presence booleans), but the terminal summary never displays it. Showing it in the scan output (something like "AI-assisted: 34% of your commits carry agent co-author trailers") would make the honesty visible before anything uploads. This is presentation only: same bundle, no new fields.
2. Count human co-author trailers (needs the data-boundary process)
Pair-programmed commits with human Co-authored-by trailers are invisible today: the trailer is neither counted nor represented. A bounded field like pair_commit_count would represent pairing honestly instead of ignoring it. This is a NEW bundle field, so per this repo's rules it needs this discussion first, then a schema version bump, docs/schema.md and CHANGELOG entries, and privacy tests. Open questions: does a count alone carry enough meaning? Should it distinguish agent trailers (already counted) from human ones? Is there any privacy concern in counting co-authored commits (the count is aggregate, no names travel)?
3. Defense-side weighting (out of scope here, noted for completeness)
Question generation could lean toward direction-and-decision questions for capabilities with heavy agent involvement. That lives server-side, outside this repo, but the signal it would consume is the ai_workflow data above.
Opinions welcome, especially on whether item 2's field earns its place in the bundle.
Raised by a Product Hunt review: "not clear yet how it handles pair-programmed or heavily AI-assisted commits when it comes time to defend the work, would be good to know upfront if that gets flagged differently."
The policy answer is now in docs/faq.md: AI-assisted work is never flagged as lesser, the bundle carries bounded agent-involvement signals, and pair commits inherit git's one-author-per-commit model. But the review points at real product gaps beyond documentation:
1. Show the AI-involvement signals upfront (no schema change)
The bundle already carries
ai_workflow(agent co-authorship counts, tool-presence booleans), but the terminal summary never displays it. Showing it in the scan output (something like "AI-assisted: 34% of your commits carry agent co-author trailers") would make the honesty visible before anything uploads. This is presentation only: same bundle, no new fields.2. Count human co-author trailers (needs the data-boundary process)
Pair-programmed commits with human
Co-authored-bytrailers are invisible today: the trailer is neither counted nor represented. A bounded field likepair_commit_countwould represent pairing honestly instead of ignoring it. This is a NEW bundle field, so per this repo's rules it needs this discussion first, then a schema version bump, docs/schema.md and CHANGELOG entries, and privacy tests. Open questions: does a count alone carry enough meaning? Should it distinguish agent trailers (already counted) from human ones? Is there any privacy concern in counting co-authored commits (the count is aggregate, no names travel)?3. Defense-side weighting (out of scope here, noted for completeness)
Question generation could lean toward direction-and-decision questions for capabilities with heavy agent involvement. That lives server-side, outside this repo, but the signal it would consume is the ai_workflow data above.
Opinions welcome, especially on whether item 2's field earns its place in the bundle.