ContextProxy fix - constructor should not be async

[cte]

Context

I ran into an annoying race condition in the evals in which we attempt to write to the secret state while it's already being asynchronously initialized, and the values I want to write get clobbered. This is caused by the ContextProxy's constructor kicking off an async function call w/o allowing us to await it.

Additionally, I don't see a reason to allow arbitrary key names in ContextProxy, so I added full type safety to it.

I also further simplified the RooCodeAPI which allowed me to clean up some of the e2e test code.

Implementation

Screenshots

before	after

How to Test

Get in Touch

---

Important

Refactor ContextProxy to remove async constructor, enhance RooCodeAPI with new methods, and update tests and configurations accordingly.

• ContextProxy:
  • Refactor ContextProxy to make constructor non-async and add initialize() method.
  • Add type safety for GlobalStateKey and SecretKey.
• RooCodeAPI:
  • Add cancelTask() and setConfiguration() methods.
  • Remove setCustomInstructions() and getCustomInstructions().
• Tests:
  • Update tests in contextProxy.test.ts and ClineProvider.test.ts to reflect changes in ContextProxy and RooCodeAPI.
  • Add subtasks.test.ts for testing subtask cancellation and resumption.
• Misc:
  • Rename .env.integration to .env.local in code-qa.yml and related files.
  • Update knip.json to ignore e2e/** and other paths.

^{This description was created by for 4b6def5. It will automatically update as commits are pushed.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 80d1fae

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
roo-cline	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cte]

Rename this file for consistency.

[ellipsis-dev]

The pull request involves changes across multiple areas, including CI updates, refactoring, and test updates. While these changes contribute to a common goal of improving the codebase, they span different areas of the project. Consider splitting the pull request into smaller, more focused pull requests if the changes are not tightly interconnected. For example, CI updates could be separated from refactoring tasks, and test updates could be handled in a separate pull request. This approach can help streamline the review process and ensure each set of changes receives the attention it deserves.

[cte]

We log this too much (it's really noisy in the evals). Let's only log an error if all attempts fail.

[mrubens]

Is this a generated file? Or are we going to need to remember to keep it up to date?

[cte]

There should be full type safety, so you will be forced to keep this up to date. This is intended to the be the source of truth, and is not generated. If you're noticing the redundancy between this type and the SECRET_KEYS constant, you can see how I handle the out-of-date problem with the following:

type CheckSecretKeysExhaustiveness = Exclude<SecretKey, (typeof SECRET_KEYS)[number]> extends never ? true : false

const _checkSecretKeysExhaustiveness: CheckSecretKeysExhaustiveness = true

[cte]

(If you know of a better way to enumerate the possible keys without placing a constant in the .d.ts file LMK).

[cte]

Skipping this for now until we can fix it... CC @mrubens @cannuri

[mrubens]

Sounds good, it's been flaking for me