refactor-execute

## TizenFX AI Bot Universal Task Pipeline (Refactoring / Feature Combined) ### Overview A universal automation pipeline that sequentially processes GitHub Issues labeled `ai-task`. The task mode is dynamically determined based on the `[Type: Refactoring]` keyword in the issue body or explicit instructions in comments. ### Repository - **Repo**: samsung/TizenFX (GitHub) - **CLI**: `gh` CLI (authenticated) --- ### Pipeline Flow ``` ⓪ Discover target Issues (ai-task) → ① Determine task mode (Refactoring vs Feature/Bug) → [Refactoring] Refactor + guarantee API preservation → Build → Benchmark → PR → [Feature/Bug] Implement feature + tests → Build → PR ``` --- ### Stage ⓪: Universal Issue Discovery ```bash gh issue list --repo samsung/TizenFX --label "ai-task" --state open --json number,title,createdAt --jq 'sort_by(.createdAt) | .[]' ``` - Process the oldest issue first - **Process at most 2 issues per run** (to maintain quality) - Always terminate after 2 issues even if more are pending --- ### Stage ①: Mode Determination and Feedback Absorption Fetch the selected issue details and comments: ```bash gh issue view {NUMBER} --repo samsung/TizenFX --comments ``` **Mode dispatch criteria:** 1. **[Refactoring mode]**: The issue body contains `[Type: Refactoring]`, or comments explicitly request refactoring/optimization. → Apply benchmark and rollback stages. 2. **[Feature-centric mode]**: Any other bug fix or feature request. → Skip benchmark, focus on unit test validation. --- ### Stage ②: Branch Creation and Pre-Validation 1. Clone or update the repository: ```bash gh repo clone samsung/TizenFX || (cd TizenFX && git checkout main && git pull) ``` 2. Create a working branch: ```bash git checkout -b ai-task/issue-{ID} ``` 3. **[Refactoring mode]** Self-reflection on potential API compatibility breaks: - Enumerate public API surface of the target area - Verify by design that the API signature remains unchanged after the refactor --- ### Stage ③: Code Modification - Modify source per the analysis/plan in the issue - **Refactoring mode**: Strictly preserve state/behavior, keep public API signatures intact - **Feature-centric mode**: Implement per spec, account for edge cases --- ### Stage ④: Build Verification and Testing 1. Build verification (required): ```bash dotnet build ``` → Must have 0 errors. Fix errors and rebuild if any occur. 2. **[Feature-centric mode]** Unit tests: ```bash dotnet test ``` → Existing tests must pass. Add missing test cases when necessary. --- ### Stage ⑤: [Refactoring Mode Only] Benchmark and Rollback Validation 1. Add a comparative benchmark to `test/Tizen.Benchmark.Gallery/` 2. Attempt to deploy and run on an `sdb` device **When sdb-related errors/issues occur (device not connected, deploy failure, execution error, etc.):** - **Pass (skip)** the benchmark stage - Post a comment on the PR explaining why the benchmark was skipped: ```bash gh pr comment {PR_NUMBER} --repo samsung/TizenFX --body "⚠️ **Benchmark skipped**: Encountered an issue with sdb device connection/deployment/execution, so the benchmark could not be run. Manual benchmark verification is required. Error: {error summary}" ``` - Also note "Benchmark: skipped (sdb error)" in the PR Verification section **On successful execution:** - If the execution log shows a **performance regression of 5% or more (median)**, automatically roll back the code: ```bash git checkout -- . ``` → After rollback, retry from Stage ③ with a different approach (max 1 retry) → If a regression persists on retry, leave a comment on the issue and move to the next issue --- ### Stage ⑥: PR Creation and Issue Linking 0. Perform a final .NET expert review over the full set of changes. 1. Commit and push changes: ```bash git add -A git commit -m "Refactor: {change summary} (Fixes #{ID})" git push origin HEAD ``` 2. Write the PR description (pr_description.md): ```markdown ## Summary {Summary of the changes} ## Changes {List of changed files and what changed in each} ## Mode {Refactoring / Feature} ## Verification - [ ] Build: passed - [ ] Tests: {passed / N/A} - [ ] Benchmark: {result summary / skipped (sdb error: reason) / N/A} Fixes #{ID} ``` 3. Create the PR: ```bash gh pr create --repo samsung/TizenFX --title "[AI Task] {task summary}" --body-file pr_description.md --label "ai-task" ``` 3-1. Verify and ensure the label is applied: ```bash gh pr view --repo samsung/TizenFX --json labels --jq '.labels[].name' | grep -q "ai-task" || \ gh pr edit --repo samsung/TizenFX --add-label "ai-task" ``` 4. After processing the current issue, if fewer than 2 issues have been handled and more are queued, return to Stage ⓪. **Always terminate once 2 issues have been processed.** --- ### Constraints - **At most 2 issues per run** (this limit is absolute) - When performing refactoring-only changes, behavior preservation is mandatory - If build errors cannot be resolved in 2 consecutive attempts, comment on the issue and skip it - Prefer small, reviewable PRs over large sweeping changes ### Reporting - Processed issue numbers and links - Created PR links - Task mode per issue (Refactoring / Feature) - Benchmark result (where applicable) or skip reason - Reason for any skipped issues