docs: define contribution scope and simplify proposal forms

Define REA contribution scope and fail closed on unresolved integration boundaries.

Make proposal forms easier to complete with structured choices, explicit unknowns, and optional technical details; welcome exploratory drafts while retaining maintainer review before integration.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,8 @@
 blank_issues_enabled: false
 contact_links:
+  - name: Contribution scope and integration requirements
+    url: https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope
+    about: Check supported capabilities, excluded workflows, and the fail-closed integration rule before proposing a feature.
   - name: REA Documentation
     url: https://github.com/morluto/rea#readme
     about: Read the README and AGENTS.md for usage guides and configuration details.

.github/ISSUE_TEMPLATE/design_discussion.yml

@@ -1,5 +1,5 @@
 name: Design discussion
-description: Resolve an REA architecture, provider, or contract question before implementation
+description: Discuss an REA architecture, provider, contract, or scope decision
 title: "[Design] "
 labels:
   - enhancement
@@ -9,7 +9,12 @@ body:
     attributes:
       value: |
         Use this for a substantial provider, public/persisted contract, or
-        authority-boundary decision. Keep one decision per discussion.
+        authority-boundary decision. One question and a short explanation are
+        enough to start. Choose "Not sure yet" where needed; maintainers can help
+        with technical details, alternatives, and verification.
+
+        Read the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope).
+        Unresolved boundaries block integration, not opening a discussion.
 
   - type: checkboxes
     id: before-submitting
@@ -18,14 +23,16 @@ body:
       options:
         - label: I searched the open and closed issues and pull requests for a related discussion.
           required: true
-        - label: I removed credentials, tokens, private paths, and sensitive target data.
+        - label: I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here.
+          required: true
+        - label: This discussion does not include credentials, private samples, or sensitive target data.
           required: true
 
   - type: textarea
     id: decision
     attributes:
       label: Decision needed
-      description: State the exact question maintainers need to resolve.
+      description: What would you like maintainers to help decide? A short question is enough.
       placeholder: Should REA ... or ...?
     validations:
       required: true
@@ -34,23 +41,57 @@ body:
     id: context-evidence
     attributes:
       label: Context and evidence
-      description: Explain why the decision is needed now. Separate observed behavior, derived evidence, and inference.
+      description: Explain the problem or motivation. If you have evidence, distinguish observed behavior from ideas or guesses.
+    validations:
+      required: true
+
+  - type: dropdown
+    id: target-interaction
+    attributes:
+      label: Expected interaction with targets
+      description: >-
+        Select all known effects, including upstream tool behavior. Add "Not sure
+        yet" if anything is unclear. Use "No target interaction" only on its own.
+        These selections help discussion and do not establish scope approval.
+      multiple: true
+      options:
+        - Read existing files or captured data
+        - Launch or attach to a process
+        - Inject instrumentation or run scripts/code
+        - Change process memory or registers
+        - Write or change files/configuration
+        - Contact network services
+        - Recover protected code or work around protections
+        - No target interaction (documentation or usability only)
+        - Not sure yet
     validations:
       required: true
 
   - type: textarea
     id: boundary-invariants
     attributes:
-      label: Boundary and invariants
-      description: Identify the owning layer, provider/bridge boundary, artifact or evidence invariants, and any process or authorization constraints.
-    validations:
-      required: true
+      label: Boundary details (optional)
+      description: >-
+        If known, clarify target selection, selected effects, provider boundaries,
+        non-goals, or evidence invariants. Leave blank if you need help identifying
+        them. Do not include private samples or proof-of-authorization documents.
 
   - type: textarea
     id: options
     attributes:
       label: Options and tradeoffs
-      description: Compare a small number of viable approaches, including platform, compatibility, safety, evidence, and maintenance costs.
+      description: Optional approaches or tradeoffs. One idea is enough; maintainers can help compare alternatives.
+
+  - type: dropdown
+    id: verification-readiness
+    attributes:
+      label: Verification available so far
+      description: Pick the closest match. An idea without samples or test results is welcome.
+      options:
+        - Idea only; I need help defining checks
+        - I can suggest a sample or manual check
+        - I have a prototype or observed results
+        - Not sure yet
     validations:
       required: true
 
@@ -58,9 +99,10 @@ body:
     id: success-criteria
     attributes:
       label: Success criteria and open questions
-      description: State what outcome would settle the decision and list only unresolved questions that could change the choice.
-    validations:
-      required: true
+      description: >-
+        Optional expected output, sample, possible check, or unresolved question.
+        A complete test plan is not required to start; maintainers and implementers
+        will resolve material verification gaps before integration.
 
   - type: textarea
     id: references

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -8,9 +8,13 @@ body:
   - type: markdown
     attributes:
       value: |
-        Keep one primary capability or workflow outcome per request. For a
-        substantial provider, public contract, or architecture change, explain
-        the decision maintainers need to make before implementation.
+        Describe one problem and the outcome you would like. Short answers are
+        welcome. Choose "Not sure yet" wherever needed; you do not need code, a
+        finished design, or a complete test plan to propose an idea.
+
+        Read the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope).
+        Maintainers can help resolve scope and technical questions. Unresolved
+        boundaries block integration, not opening a request for discussion.
 
   - type: checkboxes
     id: before-submitting
@@ -19,7 +23,9 @@ body:
       options:
         - label: I searched the open and closed issues and pull requests for a related proposal.
           required: true
-        - label: I removed credentials, tokens, private paths, and sensitive target data.
+        - label: I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here.
+          required: true
+        - label: This request does not include credentials, private samples, or sensitive target data.
           required: true
 
   - type: dropdown
@@ -36,6 +42,7 @@ body:
         - MCP or agent integration
         - Documentation
         - Other
+        - Not sure yet
     validations:
       required: true
 
@@ -43,7 +50,7 @@ body:
     id: current-limitation
     attributes:
       label: Current limitation
-      description: What user or agent workflow is blocked, ambiguous, or unnecessarily difficult today?
+      description: What are you trying to understand or do, and what is difficult today? A short example is enough.
     validations:
       required: true
 
@@ -51,23 +58,69 @@ body:
     id: use-cases
     attributes:
       label: Use cases
-      description: Give concrete applications, targets, callers, or investigation workflows. Explain why current tools are insufficient.
-    validations:
-      required: true
+      description: Optional additional examples of applications, targets, or callers. Leave blank if covered above.
 
   - type: textarea
     id: desired-outcome
     attributes:
       label: Desired outcome and success criteria
-      description: Describe observable behavior, inputs, outputs, evidence, and compatibility criteria that would make this useful.
+      description: What would a useful result look like? Describe the output or behavior you want; implementation details are optional.
+      placeholder: For a selected APK, show whether it is packed and include the detection evidence.
+    validations:
+      required: true
+
+  - type: dropdown
+    id: target-interaction
+    attributes:
+      label: Expected interaction with targets
+      description: >-
+        Select all known effects, including upstream tool behavior. Add "Not sure
+        yet" if anything is unclear. Use "No target interaction" only on its own.
+        These selections help discussion and do not establish scope approval.
+      multiple: true
+      options:
+        - Read existing files or captured data
+        - Launch or attach to a process
+        - Inject instrumentation or run scripts/code
+        - Change process memory or registers
+        - Write or change files/configuration
+        - Contact network services
+        - Recover protected code or work around protections
+        - No target interaction (documentation or usability only)
+        - Not sure yet
     validations:
       required: true
 
   - type: textarea
     id: boundaries
     attributes:
-      label: Authority boundaries and non-goals
-      description: Call out process execution, target mutation, provider licensing, evidence provenance, supported platforms, and work that should remain out of scope.
+      label: Target and scope details (optional)
+      description: >-
+        If known, name the target/platform, clarify selected effects, or list a
+        non-goal or scope question. You can leave this blank; maintainers can help.
+        Do not include private samples or proof-of-authorization documents.
+
+  - type: dropdown
+    id: verification-readiness
+    attributes:
+      label: Verification available so far
+      description: Pick the closest match. An idea without samples or test results is welcome.
+      options:
+        - Idea only; I need help defining checks
+        - I can suggest a sample or manual check
+        - I have a prototype or observed results
+        - Not sure yet
+    validations:
+      required: true
+
+  - type: textarea
+    id: verification
+    attributes:
+      label: Verification details (optional)
+      description: >-
+        Share an expected output, a possible check, or existing results if you have
+        them. Self-owned or appropriately licensed samples can help, but are not
+        required to open a request. Do not attach private or sensitive data.
 
   - type: textarea
     id: alternatives

.github/pull_request_template.md

@@ -19,17 +19,39 @@ describe the use case and observable outcome. -->
 <!-- Explain the chosen approach, why it fits REA's architecture, and what is
 intentionally not included. -->
 
+Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope).
+Unresolved scope, authority, side effects, or required verification block
+integration. Link the required maintainer scope decision for new providers or
+capabilities involving target execution, injection, mutation, or protection
+recovery; ordinary fixes within existing boundaries may state "not applicable".
+Draft PRs may leave the scope decision pending and the final review checklist
+unchecked. Maintainers can help resolve open questions.
+
 ## Contract and boundary impact
 
-<!-- Complete the applicable lines; use "none" or "not applicable" explicitly. -->
+<!-- Short answers are welcome. Complete applicable lines; mark unresolved facts as "unknown".
+Use "none" or "not applicable" only when established. -->
 
 - Semantic owner and earliest changed stage:
+- Contribution scope fit and linked maintainer decision:
 - CLI and MCP/tool-catalog contract:
 - Provider, bridge, target-format, or platform compatibility:
 - Evidence, artifact, provenance, or reconstruction contract:
-- Process execution, authorization, cleanup, or containment impact:
+- Target selection, authority, upstream behavior, and cleanup details (if applicable):
 - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact (CI generates and validates ignored catalogs and `skills/`; edit authored instructions in `.agents/skills/reverse-engineer-anything/` and never commit build outputs):
 
+Expected effects (check known effects; use documentation-only on its own).
+Unchecked items do not establish absence; leave uncertainties visible.
+
+- [ ] Read existing files or captured data.
+- [ ] Launch or attach to a process.
+- [ ] Inject instrumentation or run scripts/code.
+- [ ] Change process memory, registers, files, or configuration.
+- [ ] Contact network services.
+- [ ] Recover protected code or work around protections.
+- [ ] Documentation or usability only; no target interaction.
+- [ ] Not sure yet; investigation or maintainer guidance needed.
+
 ## Evidence and regression coverage
 
 <!-- State whether evidence is executed, source-derived, or proposed. For fixes,
@@ -68,9 +90,13 @@ limits, security/privacy/containment implications, and meaningful proof gaps. --
 - Package or release metadata impact:
 - Security, privacy, process, or containment review:
 
-## Review checklist
+## Before merge
+
+<!-- Draft PRs may leave pending items unchecked. Resolve material scope and
+authority questions before integration. -->
 
 - [ ] This PR addresses a concrete problem or an agreed enhancement.
+- [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
 - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`.
 - [ ] Related issue is linked, or the reason for not linking one is stated above.
 - [ ] Tests cover changed observable behavior and meaningful failure paths.