Update README.md

[Keyrxng]

Resolves https://www.github.com/ubiquity-os/plugins-wishlist/issues/45

[ubqbot]

To determine what's missing compared to the specification, let's break down the changes in the pull request and compare them to the outlined requirements:

Specification Requirements:

1. Draft Creation: The pull request should be initially opened as a draft.
2. Finalization: When ready for review, it should be converted to a finalized pull request by the contributor.
3. Context Consumption: The bot should consume the issue specification and pull diff into its context.
4. Actionable Feedback: The bot should provide actionable feedback for what is missing from the specification.
5. Review State: If the pull request does not meet the specification, the bot should change the review state to requested changes and convert the pull back to draft. If it passes, it should leave the state as commented.
6. Collaborator Intervention: If a collaborator finalizes the draft, the bot should stop further interventions.
7. Inspection Trigger: The inspection should be triggered only during initial creation and when a draft is finalized by the pull author.

Pull Request Changes:

• Added new listeners for pull_request.opened and pull_request.ready_for_review events in manifest.json.
• Implemented a new performPullPrecheck function to handle pull request checks.
• Introduced logic to fetch issue specifications and pull request diffs.
• Added functionality to find ground truths from the issue specification.
• Created a callback proxy to handle different GitHub events.
• Updated the plugin to use the new callback proxy for event handling.

Missing or Incomplete Aspects:

1. Draft Handling: Ensure that the pull request is initially opened as a draft. The current implementation does not explicitly check for this condition when the pull request is created.
2. Collaborator Check: The logic to determine if a collaborator has finalized the draft is not clearly implemented. Ensure that the bot backs off if a collaborator finalizes the pull request.
3. Review Limitation: The specification mentions limiting reviews to one per day to prevent abuse. This limitation is not addressed in the current implementation.
4. CI Passing Check: Although not included in the main specification, ensuring CI is passing is mentioned as a bonus task. Consider implementing this check if feasible.
5. Model Selection: The specification suggests using the o1 model, but alternatives like 4o or 3.5 sonnet should be considered if o1 is unavailable. Ensure the model selection logic is implemented.

Recommendations:

• Implement checks to ensure the pull request is initially opened as a draft.
• Add logic to verify if a collaborator has finalized the draft and prevent further bot interventions in such cases.
• Introduce a mechanism to limit the number of reviews to one per day.
• Consider adding a CI passing check if it aligns with the project's goals.
• Ensure the model selection logic is robust and aligns with the specification's preferences.

By addressing these missing or incomplete aspects, the pull request will better align with the specification requirements.

[ubqbot]

To determine what's missing compared to the specification, let's break down the changes in the pull request and compare them against the provided specification:

Specification Checklist:

1. Initial Draft Requirement: The pull request must be initially opened as a draft.
2. Finalization for Review: The pull request should be converted from draft to finalized for review.
3. Context Consumption: The bot should consume the issue specification and the pull diff into its context.
4. Actionable Feedback: The bot should provide actionable feedback for any discrepancies from the specification.
5. Review State Management: If the pull request does not meet specifications, it should be converted back to draft and request changes. If it meets specifications, it should be marked as 'commented' without approval.
6. Collaborator Intervention: If a collaborator changes the pull request back to finalized, the bot should refrain from intervening.
7. CI Checks: Optionally ensure CI is passing, but handle separately due to external factors.
8. Daily Review Limit: Implement a daily limit on bot reviews per user to prevent abuse.

Pull Request Analysis:

• Draft Status: Ensure the pull request was initially opened as a draft.
• Finalization Trigger: Check if the pull request was converted from draft to finalized by the author.
• Specification Compliance: Verify if the changes in the pull request align with the issue specification.
• Feedback Mechanism: Ensure the bot provides clear feedback on any missing elements or discrepancies.
• State Management: Confirm that the bot can convert the pull request back to draft if needed and mark it as 'commented' if it meets specifications.
• Collaborator Handling: Ensure the bot does not intervene if a collaborator finalizes the pull request.
• CI Handling: Consider CI status separately, as it may not be within the pull author's control.
• Review Limit: Check if there is a mechanism to limit reviews to one per day per user.

Conclusion:

Based on the diff provided, the pull request seems to address the specification requirements by implementing a system to handle draft status, finalization, context consumption, feedback, and state management. However, ensure that the bot's logic for collaborator intervention and daily review limits is correctly implemented and tested. Additionally, CI checks should be handled separately as per the specification.

[ubqbot]

The pull request appears to meet the specifications outlined in the issue. Here is a summary of the key points and how they align with the specification:

1. Pull Request Flow:

   • The pull request was initially opened as a draft, which aligns with the requirement that contributors must open their pull requests as drafts.
   • The changes include logic to handle the transition from draft to finalized pull requests, ensuring that the bot only intervenes when the author finalizes the draft.

2. Bot Behavior:

   • The bot is designed to analyze the issue specification and the pull request diff, providing actionable feedback if the pull request does not meet the specification.
   • The logic for converting the pull request back to a draft and leaving a comment without approval if it meets the specification is implemented.

3. Collaborator Intervention:

   • The bot is set up to back off if a collaborator changes the pull request from draft to finalized, which is in line with the specification.

4. Optional Features:

   • There is no explicit mention of CI checks or limiting reviews to one per day in the diff, but these are optional features and may be handled in other tasks.

Overall, the pull request seems to fulfill the requirements specified in the issue. If there are any specific areas you would like me to focus on or if there are additional specifications not covered here, please let me know!

[Keyrxng]

Ground Truths:

[
  'The bot should initiate review when a pull request is created as a draft and finalized by the contributor.',
  'The bot should parse the issue specification and pull request diff to assess compliance.',
  'If the pull request does not meet the specification, the bot should provide actionable feedback and change the review state to requested changes.',
  'The bot should convert non-compliant pulls back to draft status if they fail the specification check.',
  "The bot should only leave a 'commented' state for pulls that meet the specification.",
  'If a collaborator re-finalizes a draft pull, the bot should stop further interventions.',
  'The inspection process should be triggered only during initial creation and when a draft is finalized by the pull author.'
]
[
  'The bot should verify that the pull request is initially opened as a draft.',
  'The bot should check for changes from draft to finalized pull request status for initiating review.',
  'The bot needs to check pull request diffs against the issue specification for compliance.',
  'The bot should provide actionable feedback for specification discrepancies in the review.',
  'If the pull request does not meet specifications, the bot should convert it back to draft and request changes.',
  "If the pull request meets specifications, the bot should mark it as 'commented' without approval.",
  'The bot must refrain from intervening if a collaborator changes the pull request back to finalized.',
  'The bot’s intervention should be limited to triggers on pull creation and author-led status changes.',
  'Optionally handle Continuous Integration (CI) checks separately due to external factors.',
  'Consider implementing a daily limit on bot reviews per user to prevent abuse of the review system.'
]
[
  'The contributor must initially open the pull request as a draft.',
  'When the pull request is ready for review, the contributor should convert it to a finalized pull request.',
  'The bot should analyze the issue specification along with the pull request diff.',
  'The bot should provide actionable feedback indicating any missing specifications.',
  "If the pull request doesn't meet the specification, the bot should require changes and revert the pull back to a draft.",
  'If the pull request meets the specification, the bot should leave a comment without approval.',
  'The bot must not intervene if a collaborator changes the pull request from draft to finalized.',
  'The bot should only conduct inspections upon pull creation and when the author finalizes a draft.',
  'Optional: Ensure CI passes, but account for potential external failures.',
  'Optional: Limit bot reviews to one per day per contributor to prevent excessive use for minor changes.'
]