Merge from Cline

.hai/skills/create-pull-request/SKILL.md → .agents/skills/create-pull-request/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-pull-request
-description: Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, and PR creation using the gh CLI tool.
+description: Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, PR template usage, and PR creation using the gh CLI tool.
 ---
 
 # Create Pull Request

.changeset/social-toes-melt.md

@@ -0,0 +1,5 @@
+---
+"hai-build-code-generator": patch
+---
+
+merge from cline version 3.72.0

.github/copilot-instructions.md

@@ -0,0 +1,58 @@
+# Copilot Instructions for Cline
+
+This is a VS Code extension. Read `.clinerules/general.md` for tribal knowledge and nuanced patterns.
+
+## Architecture
+- **Core** (`src/`): `extension.ts` → `WebviewProvider` → `Controller` (single source of truth) → `Task` (agent loop).
+- **Webview** (`webview-ui/`): React/Vite app. State via `ExtensionStateContext.tsx`, synced through message passing.
+- **CLI** (`cli/`): React Ink terminal UI sharing core logic. Update CLI when changing webview features.
+- **Communication**: Protobuf-defined gRPC-like protocol over VS Code message passing. Schemas in `proto/`.
+- **MCP**: `src/services/mcp/McpHub.ts`.
+
+## Build & Test (Critical — non-obvious commands)
+- **Build**: `npm run compile` — NOT `npm run build`.
+- **Watch**: `npm run watch` (extension + webview).
+- **Protos**: `npm run protos` — run **immediately** after any `.proto` change. Generates into `src/shared/proto/`, `src/generated/`.
+- **Tests**: `npm run test:unit`. After prompt/tool changes: `UPDATE_SNAPSHOTS=true npm run test:unit`.
+
+## Protobuf RPC Workflow (4 steps)
+1. **Define** in `proto/cline/*.proto`. Naming: `PascalCaseService`, `camelCase` RPCs, `PascalCase` Messages. Use `common.proto` shared types for simple data.
+2. **Generate**: `npm run protos`.
+3. **Backend handler**: `src/core/controller/<domain>/`. 
+4. **Frontend call**: `UiServiceClient.myMethod(Request.create({...}))`.
+- Adding enums (e.g. `ClineSay`) → also update `src/shared/proto-conversions/cline-message.ts`.
+
+## Adding API Providers (silent failure risk)
+Three proto conversion updates are **required** or the provider silently resets to Anthropic:
+1. `proto/cline/models.proto` — add to `ApiProvider` enum.
+2. `convertApiProviderToProto()` in `src/shared/proto-conversions/models/api-configuration-conversion.ts`.
+3. `convertProtoToApiProvider()` in the same file.
+
+Also update: `src/shared/api.ts`, `src/shared/providers/providers.json`, `src/core/api/index.ts`, `webview-ui/.../providerUtils.ts`, `webview-ui/.../validate.ts`, `webview-ui/.../ApiOptions.tsx`, and `cli/src/components/ModelPicker.tsx`.
+
+For Responses API providers: add to `isNextGenModelProvider()` in `src/utils/model-utils.ts` and set `apiFormat: ApiFormat.OPENAI_RESPONSES` on models.
+
+## Adding Tools to System Prompt (5+ file chain)
+1. Add enum to `ClineDefaultTool` in `src/shared/tools.ts`.
+2. Create definition in `src/core/prompts/system-prompt/tools/` (export `[GENERIC]` minimum).
+3. Register in `src/core/prompts/system-prompt/tools/init.ts`.
+4. Whitelist in `src/core/prompts/system-prompt/variants/*/config.ts` for each model family.
+5. Handler in `src/core/task/tools/handlers/`, wire in `ToolExecutor.ts`.
+6. If tool has UI: add `ClineSay` enum in proto → `ExtensionMessage.ts` → `cline-message.ts` → `ChatRow.tsx`.
+7. Regenerate snapshots: `UPDATE_SNAPSHOTS=true npm run test:unit`.
+
+## Modifying System Prompt
+Modular: `components/` (shared) + `variants/` (model-specific) + `templates/` (`{{PLACEHOLDER}}`). Variants override components via `componentOverrides` in `config.ts` or custom `template.ts`. XS variant is heavily condensed inline. Always regenerate snapshots after changes.
+
+## Global State Keys (silent failure risk)
+Adding a key requires: type in `src/shared/storage/state-keys.ts`, read via `context.globalState.get()` in `src/core/storage/utils/state-helpers.ts` `readGlobalStateFromDisk()`, and add to return object. Missing the `.get()` call compiles fine but value is always `undefined`.
+
+## Slash Commands (3 places)
+- `src/core/slash-commands/index.ts` — definitions.
+- `src/core/prompts/commands.ts` — system prompt integration.
+- `webview-ui/src/utils/slash-commands.ts` — webview autocomplete.
+
+## Conventions
+- **Paths**: Always use `src/utils/path` helpers (`toPosixString`) for cross-platform compatibility.
+- **Logging**: `src/shared/services/Logger.ts`.
+- **Feature flags**: See PR #7566 as reference pattern.

.github/pull_request_template.md

@@ -1,6 +1,46 @@
+<!--
+Thank you for contributing to Cline!
+
+⚠️ Important: Before submitting this PR, please ensure you have:
+- For feature requests: Created a discussion in our Feature Requests discussions board https://github.com/cline/cline/discussions/categories/feature-requests and received approval from core maintainers before implementation
+- For all changes: Link the associated issue/discussion in the "Related Issue" section below
+
+Limited exceptions:
+Small bug fixes, typo corrections, minor wording improvements, or simple type fixes that don't change functionality may be submitted directly without prior discussion.
+
+Why this requirement?
+We deeply appreciate all community contributions - they are essential to Cline's success! To ensure the best use of everyone's time and maintain project direction, we use our Feature Requests discussions board to gauge community interest and validate feature ideas before implementation begins. This helps us focus development efforts on features that will benefit the most users.
+-->
+
+### Related Issue
+
+<!-- Replace XXXX with the issue number that this PR addresses -->
+**Issue:** #XXXX
+
 ### Description
 
-<!-- Describe your changes in detail. What problem does this PR solve? -->
+<!-- 
+Help reviewers understand your changes by making this PR readable and well-organized:
+
+- What problem does this PR solve?
+- Why were these changes introduced and what purpose do they serve?
+- For larger changes, provide context about your approach and reasoning
+
+Small PRs may need minimal description, but larger changes benefit from explaining where you're coming from. Much of this context can be in the linked issue above, so feel free to reference it rather than repeating everything here.
+-->
+
+### Test Procedure
+
+<!-- 
+Please walk us through your testing approach and thought process. This helps reviewers understand that you've thoroughly considered the impact of your changes:
+
+- How did you test this change?
+- What could potentially break and how did you verify it doesn't?
+- What existing functionality might be affected and how did you check it still works?
+- Why are you confident this is ready for merge?
+
+We're not looking for exhaustive documentation - just evidence that you've thought through the implications of your changes and tested accordingly.
+-->
 
 ### Type of Change
 
@@ -20,13 +60,20 @@
 
 -   [ ] Changes are limited to a single feature, bugfix or chore (split larger changes into separate PRs)
 -   [ ] Tests are passing (`npm test`) and code is formatted and linted (`npm run format && npm run lint`)
--   [ ] I have created a changeset using `npm run changeset` (required for user-facing changes)
--   [ ] I have reviewed [contributor guidelines](https://github.com/presidio-oss/cline-based-code-generator/blob/main/CONTRIBUTING.md)
+-   [ ] I have reviewed [contributor guidelines](https://github.com/cline/cline/blob/main/CONTRIBUTING.md)
 
 ### Screenshots
 
-<!-- For UI changes, add screenshots here -->
+<!-- 
+Help reviewers quickly understand your changes:
+
+- **UI Changes**: Please include screenshots showing before/after states
+- **Complex Workflows**: Consider uploading a screen recording (video) if your changes involve multiple steps or state transitions
+- **Backend Changes**: Not required, but feel free to include terminal output or other evidence that demonstrates functionality
+
+This helps reviewers see what you've built without having to pull down and test your branch first.
+-->
 
 ### Additional Notes
 
-<!-- Add any additional notes for reviewers -->
+<!-- Add any additional notes for reviewers -->

.gitignore

@@ -51,3 +51,8 @@ test-results
 
 # Smoke test results (generated)
 evals/smoke-tests/results/
+
+.tui-test
+secrets.json
+tui-traces
+tests/**/cache

.hairules/general.md

@@ -14,9 +14,9 @@ This file is the secret sauce for working effectively in this codebase. It captu
 
 ## Miscellaneous
 - This is a VS Code extension—check `package.json` for available scripts before trying to verify builds (e.g., `npm run compile`, not `npm run build`).
-- When creating PRs, if the change is user-facing and significant enough to warrant a changelog entry, run `npm run changeset` and create a patch changeset. Never create minor or major version bumps. Skip changesets for trivial fixes, internal refactors, or minor UI tweaks that users wouldn't notice.
-- When adding new feature flags, see this PR as a reference https://github.com/presidio-oss/hai-build-codegen/pull/28
-- Additional instructions about making requests: @.hairules/network.md
+- When creating PRs, contributors should not create changelog-entry files. Maintainers handle release versioning and changelog curation during the release process.
+- When adding new feature flags, see this PR as a reference https://github.com/cline/cline/pull/7566
+- Additional instructions about making requests: @.clinerules/network.md
 
 ## gRPC/Protobuf Communication
 The extension and webview communicate via gRPC-like protocol over VS Code message passing.

.hairules/storage.md

@@ -0,0 +1,64 @@
+# Storage Architecture
+
+Global settings, secrets and workspace state are stored in **file-backed JSON stores** under `~/.cline/data/`. This is the shared storage layer used by VSCode, CLI, and JetBrains.
+
+## Key Abstractions
+
+### `StorageContext` (src/shared/storage/storage-context.ts)
+The entry point. Created via `createStorageContext()` and passed to `StateManager.initialize()`. Contains three `ClineFileStorage` instances:
+- `globalState` → `~/.cline/data/globalState.json`
+- `secrets` → `~/.cline/data/secrets.json` (mode 0o600)
+- `workspaceState` → `~/.cline/data/workspaces/<hash>/workspaceState.json`
+
+### `ClineFileStorage` (src/shared/storage/ClineFileStorage.ts)
+Synchronous JSON key-value store backed by a single file. Supports `get()`, `set()`, `setBatch()`, `delete()`. Writes are atomic (write-then-rename).
+
+### `StateManager` (src/core/storage/StateManager.ts)
+In-memory cache on top of `StorageContext`. All runtime reads hit the cache; writes update cache immediately and debounce-flush to disk.
+
+## ⚠️ Do NOT Use VSCode's ExtensionContext for Storage
+
+**Do not** read from or write to `context.globalState`, `context.workspaceState`, or `context.secrets` for persistent data. These are VSCode-specific and not available on CLI or JetBrains.
+
+Instead, use:
+```typescript
+// Reading state
+StateManager.get().getGlobalStateKey("myKey")
+StateManager.get().getSecretKey("mySecretKey")
+StateManager.get().getWorkspaceStateKey("myWsKey")
+
+// Writing state
+StateManager.get().setGlobalState("myKey", value)
+StateManager.get().setSecret("mySecretKey", value)
+StateManager.get().setWorkspaceState("myWsKey", value)
+```
+
+Remember that your data may be read by a different client than the one that wrote it. For example, a value written by Cline in JetBrains may be read by Cline CLI.
+
+## VSCode Migration (src/hosts/vscode/vscode-to-file-migration.ts)
+
+On VSCode startup, a migration copies data from VSCode's `ExtensionContext` storage into the file-backed stores. This runs in `src/common.ts` before `StateManager.initialize()`.
+
+- **Sentinel**: `__vscodeMigrationVersion` key in global state and workspace state — prevents re-migration.
+- **Merge strategy**: File store wins. Existing values are never overwritten.
+- **Safe downgrade**: VSCode storage is NOT cleared, so older extension versions still work.
+
+## Adding New Storage Keys
+
+1. Add to `src/shared/storage/state-keys.ts` (see existing patterns)
+2. Read/write via `StateManager` (NOT via `context.globalState`)
+3. If adding a secret, add to `SecretKeys` array in `state-keys.ts`
+
+## File Layout
+
+```
+~/.cline/
+  data/
+    globalState.json          # Global settings & state
+    secrets.json              # API keys (mode 0o600)
+    tasks/
+      taskHistory.json        # Task history (separate file)
+    workspaces/
+      <hash>/
+        workspaceState.json   # Per-workspace toggles
+```

.hairules/workflows/address-pr-comments.md

@@ -19,7 +19,7 @@ Review and address all comments on the current branch's PR.
    - Inline comments: `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments`
    - General comments: `gh pr view {pr_number} --json comments,reviews`
 
-4. Present a summary of all comments with your recommendation for each (apply, skip, or respond). Ignore bot noise (changeset-bot, CI status, etc.).
+4. Present a summary of all comments with your recommendation for each (apply, skip, or respond). Ignore bot noise (release automation, CI status, etc.).
 
 5. **Wait for my approval** before proceeding.
 

.hairules/workflows/hotfix-release.md

@@ -89,16 +89,9 @@ On the main branch, create a commit that updates:
 
 2. **package.json** - Update the version field to the new version
 
-3. **Delete changesets** for the commits being included in the hotfix. This prevents the changeset bot from including duplicate entries in the next regular release.
+3. No changelog-entry file cleanup is needed. Contributors do not create changelog-entry files in this repo.
 
-   Find and delete the changeset files associated with the selected commits:
-   ```bash
-   ls .changeset/
-   ```
-
-   Each changeset file in `.changeset/` corresponds to a PR. Read them to identify which ones belong to the commits you're hotfixing, then delete those files.
-
-**Skip running `npm run install:all`** - the automation handles outdated lockfiles.
+**Skip running `npm run install:all`** - release automation handles lockfile consistency as needed.
 
 Commit with message format: `v{VERSION} Release Notes (hotfix)`
 
@@ -107,7 +100,7 @@ In the commit body, mention:
 - List the cherry-picked commits that will be included
 
 ```bash
-git add CHANGELOG.md package.json .changeset/
+git add CHANGELOG.md package.json
 git commit -m "v3.40.1 Release Notes (hotfix)
 
 Hotfix release including:

.hairules/workflows/pr-review.md

@@ -347,8 +347,6 @@ A few notes:
 So until the settings page is update, and this is added to settings in a way that's clean and doesn't confuse new users, I don't think we can merge this. Please bear with us.
 </request_changes_comment>
 <request_changes_comment>
-Also, don't forget to add a changeset since this fixes a user-facing bug.
-
 The architectural change is solid - moving the focus logic to the command handlers makes sense. Just don't want to introduce subtle timing issues by removing those timeouts.
 </request_changes_comment>
 </example_comments_that_i_have_written_before>