life-itself/reasoncommons should remain David and Rufus's familiar collaboration surface while its work becomes connected to the app-development commons' goal and reasoning. The inspected app sync service projects accepted actions and reconciles existing mappings; creating an issue here must not be assumed to import it into the app.
Work
- Verify and document actual connection behavior, then support selecting a small set of existing issues for inbound review.
- Preserve repository/issue identity, source URL, source revision and supporting excerpts.
- Interpret an issue according to its content: action, question, problem, hypothesis or several related items. Do not force every issue into one transition action.
- Keep inferred relationships and expected effects provisional; distinguish completion criteria from observed outcomes.
- On acceptance of an action, adopt its original issue mapping rather than create another issue; preserve human-written content.
- Handle repeat imports, interrupted retries and later issue edits without silently rewriting accepted reasoning.
Acceptance criteria
Using selected real issues, an import creates bounded proposals with source links. Acceptance adopts the original action issue, rerunning does not duplicate proposals or issues, and a later source edit produces a reviewable difference. Issue closure records reported completion and does not declare success or increase throughput automatically.
Expected benefit and check
David and Rufus can explain why selected work matters and what it should change while continuing to work from GitHub. Compare the effort of this small workflow with manually maintaining both places before expanding to continuous ingestion.
Depends on the app-development commons being established and the relevant import/review path being reliable. Related: #23 (machine-readable repository exports), which is the outward reasoning-document path, not this inbound issue path.
life-itself/reasoncommons should remain David and Rufus's familiar collaboration surface while its work becomes connected to the app-development commons' goal and reasoning. The inspected app sync service projects accepted actions and reconciles existing mappings; creating an issue here must not be assumed to import it into the app.
Work
Acceptance criteria
Using selected real issues, an import creates bounded proposals with source links. Acceptance adopts the original action issue, rerunning does not duplicate proposals or issues, and a later source edit produces a reviewable difference. Issue closure records reported completion and does not declare success or increase throughput automatically.
Expected benefit and check
David and Rufus can explain why selected work matters and what it should change while continuing to work from GitHub. Compare the effort of this small workflow with manually maintaining both places before expanding to continuous ingestion.
Depends on the app-development commons being established and the relevant import/review path being reliable. Related: #23 (machine-readable repository exports), which is the outward reasoning-document path, not this inbound issue path.