@alternative-path/x-mcp 1.0.0

package/dist/agents/test-planner-context.js

@@ -0,0 +1,283 @@
+/**
+ * Embedded test planning context for the x-test-planner agent.
+ * This content is the same as CURSOR_CONTEXT_TEST_PLANNING.md but is bundled
+ * in the MCP server so the agent always uses a consistent, non-editable context.
+ */
+export const TEST_PLANNER_CONTEXT = `# Cursor Context for Test Planning
+
+This file provides a comprehensive, reusable context for test planning, test case/scenario creation, and automation workflow design. Use this as a template for any new project or feature to ensure consistency, completeness, and efficiency in your QA process.
+
+---
+
+## 1. Test Plan Structure
+
+A standard test plan should include the following sections:
+
+- **Reference Template:**
+  - [Test Plan Template (Revamped) - Confluence](https://reorg-research.atlassian.net/wiki/spaces/qe/pages/892338177/Test+Plan+Template+Revamped)
+
+- **Project & Stakeholder Details**
+  - QA start dates, stakeholders, design/epic/BDD links, QA owner
+- **Objective**
+  - Short summary of the project/feature and underlying changes
+- **Test Scope**
+  - In Scope: Features, platforms, workflows to be tested
+  - Out of Scope: Exclusions, legacy flows, non-impacted areas
+  - In Scope - Automation: What will be automated
+  - Out of Scope - Automation: What will not be automated and why
+- **Data Validation Coverage**
+  - Types of data, edge cases, negative data, and how data coverage is ensured
+- **Assumptions and Dependencies**
+  - Environment, APIs, roles, external systems, etc.
+- **Objectives**
+  - Functional, performance, security, UI/UX, data validation
+- **Test Strategy**
+  - Types of testing (unit, functional, UI, API, DB, performance, UAT, etc.)
+  - Approach: Happy path, edge/negative, integration, data, exploratory
+- **Phase Plan**
+  - Phased approach to testing (happy path, integration, edge, regression, etc.)
+- **Manual & Automated Testing**
+  - What will be covered manually vs. automated
+- **Migration/Backfilling**
+  - Data migration/validation if applicable
+- **Regression**
+  - Impacted areas, regression suite, integration points
+- **Functional Testing Considerations**
+  - Business rules, UI/UX, data, error handling, new/changed workflows
+- **Integration & Dependencies**
+  - APIs, external systems, user management, logging
+- **Non-Functional Testing**
+  - Performance, security, compatibility, scalability
+- **Automation & Test Coverage**
+  - Reuse, prioritization, data, coverage goals
+- **Operational & Monitoring**
+  - Audit logs, error monitoring, post-release validation
+- **User Scenarios & Test Cases**
+  - Table of detailed test cases and scenarios
+- **Automation Workflows**
+  - Table of automation flows covering multiple test cases
+- **Release and Revert Plan**
+- **Post Release Production Validation**
+- **Approval Table**
+
+---
+
+## 2. Test Case & Scenario Writing
+
+- **Test Case Table Columns:**
+  - Test Case ID
+  - Title
+  - Objective
+  - Steps (detailed, step-by-step)
+  - Expected Result
+  - Test Data (if applicable)
+
+- **Best Practices:**
+  - Be specific and unambiguous
+  - Cover both positive and negative scenarios
+  - Include cases that are most likely to result into bugs
+  - Include edge cases and data variations
+  - Link to requirements/user stories where possible
+  - Use clear, actionable language
+  - Be as detailed as possible
+  - Define the test steps with granularity and details
+  - Include places to look out for in the expected results and be very specific.
+  - If there are multiple places where an outcome can be or should be validated, include all those places as part of the expected result or create new test case for that.
+  - While creating test cases add test steps as well keeping in mind that the person executing these testacses and steps can only access the application using the front-end. So, add steps that can be followed from the applicaiton/navigation. Try to be as accurate with the test steps as you can.
+
+- **Example Test Case Table (Markdown):**
+
+| Test Case ID | Title | Objective | Steps | Expected Result | Test Data |
+|--------------|-------|-----------|-------|----------------|-----------|
+| TC-01 | Upload Supported Document | Verify upload and queueing of supported document types | 1. Login as user<br>2. Upload Termsheet.pdf<br>3. Queue for extraction | Document appears in dashboard with correct status and metadata | Termsheet.pdf |
+
+---
+
+## 3. Automation Workflow Design
+
+- **Workflow Table Columns:**
+  - Workflow Name
+  - Test Cases Covered (from the list of test cases generated in above sections)
+  - Workflow Steps (should cover multiple test cases per flow)
+
+- **Best Practices:**
+  - Design workflows to maximize coverage with minimal complexity
+  - Avoid overly complex flows; keep steps maintainable
+  - Reuse login, navigation, and setup steps
+  - Validate both UI and backend (API, DB) where possible
+
+- **Example Automation Workflow Table (Markdown):**
+
+| Workflow Name | Test Cases Covered | Workflow Steps |
+|--------------|--------------------|----------------|
+| Document Upload, Extraction, and Review | TC-01, TC-03, TC-04, ... | 1. Login<br>2. Upload document<br>3. Queue for extraction<br>... |
+
+---
+
+## 4. Test Data Management
+
+- Use a variety of data: valid, invalid, edge, corrupted, large/small, etc.
+- Document test data in the test case table or as a separate section
+- For automation, use data-driven approaches where possible
+
+---
+
+## 5. General Best Practices
+
+- Always link test cases to requirements/user stories/epics
+- Keep test cases atomic and independent
+- Regularly review and update test cases and workflows
+- Prioritize automation for repetitive, high-value, and regression scenarios
+- Ensure auditability and traceability (who tested what, when, and why)
+- Include negative, boundary, and exploratory tests
+- Validate error handling, security, and access control
+- Document assumptions, dependencies, and environment details
+
+---
+
+## 6. Example Section Templates
+
+### Test Case Table
+
+| Test Case ID | Title | Objective | Steps | Expected Result | Test Data |
+|--------------|-------|-----------|-------|----------------|-----------|
+| TC-01 | ... | ... | ... | ... | ... |
+
+### Automation Workflow Table
+
+| Workflow Name | Test Cases Covered | Workflow Steps |
+|---------------|-------------------|----------------|
+| ... | ... | ... |
+
+---
+
+## 7. Section for Abbreviations
+
+### Abbreviations
+ - Include a section towards the end to have abbreviations and their full forms listed
+ - List the abbreviations as bullet points
+ - If you are you not able to find a full form for any abbreviation, the use the confluence or the internet to search for that term
+
+- **Example Abbreviation Section:**
+PCDO - Private Credit and Deal Orientation
+CLO - Collateralized Loan Obligation
+
+---
+
+## 8. How to Use This Context
+
+- When starting a new test planning effort, use this as your base context
+- Fill in project-specific details, requirements, and data as needed
+- Use the tables and best practices to guide your test plan, test case, and automation workflow creation
+- Make use of the details provided with the prompt
+- **If additional information is provided with the prompt (such as BDD links, TDD links, JIRA story/task links, or Confluence links), ensure you utilize this information by thoroughly reviewing all referenced artifacts. This includes:**
+  - Visiting all provided BDD, TDD, JIRA, and Confluence links.
+  - For Confluence pages, review all child pages and any referenced or linked Confluence pages.
+  - For JIRA artifacts, review all linked JIRA issues and any referenced Confluence pages.
+  - Read all comments on both Confluence and JIRA items.
+  - Follow all references recursively to ensure complete context is gathered for the test plan.
+
+---
+
+## 8A. Test Planning Deep-Dive Checklist
+
+**When preparing the Test Plan, Test Cases, Testing Strategy, or any other relevant section, use the following checklist to guide your analysis. Answer as many of these as are applicable, and use the answers to enrich the relevant sections of your test plan.**
+
+### Functional Testing
+1. Does the design/change affect the current workflow that it is being developed for?
+2. Does the design/change affect any other transaction?
+   - List of affected transactions
+3. Does the design/change affect any existing report/calculation?
+4. List of affected reports/calculations
+5. Is there a need to create separate reporting for the design/change?
+6. Is there any existing data point that could be affected?
+7. Does it affect any other functionality?
+   - List of affected functionalities
+8. Are there any new business rules or validations introduced?
+9. How should the system behave in case of missing/invalid data?
+10. Are there any UI/UX changes? If yes, how do they impact usability?
+11. What are the expected inputs and outputs for each function or transaction?
+
+### Integration & Dependencies
+1. Any integration area affected?
+2. List of affected integration areas
+3. Does the change introduce any dependencies on third-party services or external systems?
+4. Are there any upstream or downstream data dependencies?
+5. Do any existing integrations require modification or additional validation?
+6. Are there any database schema changes? If yes, how will backward compatibility be handled?
+
+### Non-Functional Testing
+1. What are the performance benchmarks/considerations?
+2. How much time is allowed during processing?
+3. What are the payload size considerations?
+4. Are there security considerations (authentication, authorization, data encryption)?
+5. What are the scalability and concurrency requirements?
+6. Does the system handle expected and unexpected failures gracefully?
+7. Is failover or disaster recovery testing required?
+8. Are there any regulatory or compliance requirements?
+9. Are there browser/device compatibility considerations (for web or mobile applications)?
+
+### Automation & Test Coverage
+1. Are there reusable test cases from previous releases that apply to this change?
+2. Are there specific scenarios that should be prioritized for automation?
+3. What test data is required, and how will it be managed?
+4. Will exploratory testing be needed in addition to scripted test cases?
+5. Are API endpoints available for testing/automation?
+
+### Operational & Monitoring
+1. Are debug/audit logs available?
+2. How will errors be logged and monitored in production?
+3. Are there any alerting mechanisms in place for failures?
+4. What are the rollback procedures if the deployment fails?
+5. How will post-production validation be performed?
+6. What is the frequency of jobs run?
+7. What access/rights are required for QA teams?
+8. Is there a need for specific capabilities/entitlements for testing?
+
+---
+
+- **Test Strategy**
+  - Types of testing (unit, functional, UI, API, DB, performance, UAT, etc.)
+  - Approach: Happy path, edge/negative, integration, data, exploratory
+  - **Sample Test Strategy (for inspiration):**
+
+    We will start with the happy flow scenarios for the Transaction management. Here we plan to cover 65-70% of our functional requirements. Then we will move on to test the migrated data testing that will be performed at the Database layer. As migration is a major event in the functionality to be available to the users. This is critical to do as existing transaction need to be present in the system. Then, we will test integration areas such that the consumers of the transactional data are in sync with the changing transactions, for this API testing approach will be used as the integration will be done using APIs. This strategy ensures that the we have confidence in the end-to end functional, data and integration areas.
+
+    Then, we will move on to covering the edge case scenarios around the transaction management, which are more prone to break the workflow. This phase is to make sure the system is resilient to failures and error.
+
+    Finally, we will perform exploratory testing to uncover issues or perform validations to ensure completeness.
+
+    **Phase 1: Happy Flow Validation (Foundation Testing)**
+    We will begin by validating the happy flow scenarios for Transaction Management, covering approximately 65-70% of the functional requirements. This phase ensures that the fundamental workflows behave as expected under standard conditions.
+    *Why this first?*
+     - Establishes baseline functional correctness.
+     - Allows early defect detection and reduces rework in later stages.
+     - Enables smoother collaboration with development teams in case of issues.
+
+    **Phase 2: Migrated Data Validation (Data Integrity Testing)**
+    Once core functionality is validated, we will focus on migrated data testing at the database layer. Since data migration is a key event enabling this functionality, it is critical to verify that existing transactions are accurately present and available in the system post-migration.
+    *Why now?*
+     - Ensures historical transactions remain intact post-migration.
+     - Prevents discrepancies before proceeding to further functional and integration tests.
+
+    **Phase 3: Integration Testing (System Connectivity & Data Flow Testing)**
+    Next, we will validate integration areas, ensuring that consumers of transactional data are in sync with the changing transactions. This will be performed through API testing, as integration is API-driven.
+    *Why at this stage?*
+     - By now, we have confidence in functional correctness and data integrity.
+     - Ensures seamless interaction between the transaction system and external consumers.
+     - Helps detect system-wide inconsistencies before moving to deeper validation.
+
+    **Phase 4: Edge Case & Negative Scenario Testing (Resilience & Failure Handling)**
+    At this stage, we will cover edge case scenarios, which are more prone to breaking the workflow. This includes boundary conditions, invalid inputs, concurrency issues, and error handling.
+    *Why now?*
+     - Functional and integration correctness is already established, allowing us to focus on resilience.
+     - Helps assess the system's robustness in handling unexpected inputs and failures.
+
+    **Phase 5: Exploratory Testing (Final Validations & Completeness Check)**
+    Finally, we will perform exploratory testing to uncover issues that may not have been covered in structured test cases. This includes usability assessments, performance bottlenecks, and overlooked functional gaps.
+    *Why at the end?*
+     - Ensures real-world scenarios and human intuition-driven testing before deployment.
+     - Helps identify potential last-minute gaps or overlooked issues.
+
+**This context is designed to make your test planning fast, consistent, and high quality.**`;
+//# sourceMappingURL=test-planner-context.js.map

package/dist/agents/test-planner-context.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"test-planner-context.js","sourceRoot":"","sources":["../../src/agents/test-planner-context.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,MAAM,CAAC,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;4FAoRwD,CAAC"}

package/dist/agents/test-planner-prompt.d.ts

@@ -0,0 +1,34 @@
+/**
+ * x-test-planner agent: MCP prompt that delivers the standard test-planning context
+ * so test plans are consistent and repeatable without relying on a user-editable context file.
+ */
+import type { Prompt, GetPromptResult } from "@modelcontextprotocol/sdk/types.js";
+export declare const X_TEST_PLANNER_NAME = "x-test-planner";
+/**
+ * Arguments the user can supply when invoking the prompt.
+ * All are optional so the prompt can be used with minimal or rich input.
+ */
+export declare const X_TEST_PLANNER_ARGUMENTS: readonly [{
+    readonly name: "project_summary";
+    readonly description: "Short description of the project/feature to plan tests for (e.g. epic summary, user story, or change description).";
+    readonly required: false;
+}, {
+    readonly name: "links";
+    readonly description: "Optional BDD, TDD, JIRA, or Confluence links. The agent will use these to gather context for the test plan.";
+    readonly required: false;
+}, {
+    readonly name: "scope";
+    readonly description: "Optional test scope (in scope / out of scope, platforms, or specific areas to focus on).";
+    readonly required: false;
+}];
+/**
+ * Prompt definition for prompts/list.
+ */
+export declare function getTestPlannerPromptDefinition(): Prompt;
+/**
+ * Builds the prompt messages for prompts/get.
+ * Message 1: embedded context + agent instruction.
+ * Message 2: user's request (templated with project_summary, links, scope).
+ */
+export declare function getTestPlannerMessages(args?: Record<string, string>): GetPromptResult;
+//# sourceMappingURL=test-planner-prompt.d.ts.map

package/dist/agents/test-planner-prompt.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"test-planner-prompt.d.ts","sourceRoot":"","sources":["../../src/agents/test-planner-prompt.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,OAAO,KAAK,EAAE,MAAM,EAAE,eAAe,EAAiB,MAAM,oCAAoC,CAAC;AAGjG,eAAO,MAAM,mBAAmB,mBAAmB,CAAC;AAOpD;;;GAGG;AACH,eAAO,MAAM,wBAAwB;;;;;;;;;;;;EAmB3B,CAAC;AAEX;;GAEG;AACH,wBAAgB,8BAA8B,IAAI,MAAM,CAOvD;AAED;;;;GAIG;AACH,wBAAgB,sBAAsB,CAAC,IAAI,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,eAAe,CAoCrF"}

package/dist/agents/test-planner-prompt.js

@@ -0,0 +1,82 @@
+/**
+ * x-test-planner agent: MCP prompt that delivers the standard test-planning context
+ * so test plans are consistent and repeatable without relying on a user-editable context file.
+ */
+import { TEST_PLANNER_CONTEXT } from "./test-planner-context.js";
+export const X_TEST_PLANNER_NAME = "x-test-planner";
+const PROMPT_DESCRIPTION = "Standard test plan agent. Uses embedded test-planning context to produce consistent, repeatable test plans, test cases, and automation workflows without manual context files.";
+const PROMPT_TITLE = "x-test-planner";
+/**
+ * Arguments the user can supply when invoking the prompt.
+ * All are optional so the prompt can be used with minimal or rich input.
+ */
+export const X_TEST_PLANNER_ARGUMENTS = [
+    {
+        name: "project_summary",
+        description: "Short description of the project/feature to plan tests for (e.g. epic summary, user story, or change description).",
+        required: false,
+    },
+    {
+        name: "links",
+        description: "Optional BDD, TDD, JIRA, or Confluence links. The agent will use these to gather context for the test plan.",
+        required: false,
+    },
+    {
+        name: "scope",
+        description: "Optional test scope (in scope / out of scope, platforms, or specific areas to focus on).",
+        required: false,
+    },
+];
+/**
+ * Prompt definition for prompts/list.
+ */
+export function getTestPlannerPromptDefinition() {
+    return {
+        name: X_TEST_PLANNER_NAME,
+        title: PROMPT_TITLE,
+        description: PROMPT_DESCRIPTION,
+        arguments: [...X_TEST_PLANNER_ARGUMENTS],
+    };
+}
+/**
+ * Builds the prompt messages for prompts/get.
+ * Message 1: embedded context + agent instruction.
+ * Message 2: user's request (templated with project_summary, links, scope).
+ */
+export function getTestPlannerMessages(args) {
+    const projectSummary = args?.project_summary?.trim() ?? "";
+    const links = args?.links?.trim() ?? "";
+    const scope = args?.scope?.trim() ?? "";
+    const contextMessage = {
+        role: "user",
+        content: {
+            type: "text",
+            text: `${TEST_PLANNER_CONTEXT}
+
+---
+**You are the x-test-planner agent.** Use the above context for every response. Do not ask the user to provide or attach this context—it is already applied. Produce test plans, test cases, and automation workflows that follow the structure, best practices, and checklists above.`,
+        },
+    };
+    const parts = ["Create a test plan (and test cases / automation workflows as appropriate) for the following."];
+    if (projectSummary)
+        parts.push(`\n**Project/feature:**\n${projectSummary}`);
+    if (links)
+        parts.push(`\n**Links (BDD/JIRA/Confluence):**\n${links}`);
+    if (scope)
+        parts.push(`\n**Scope:**\n${scope}`);
+    if (!projectSummary && !links && !scope) {
+        parts.push("\nNo specific project or links were provided. Ask the user for a brief project/feature description and any BDD, JIRA, or Confluence links, or produce a generic test plan template they can fill in.");
+    }
+    const requestMessage = {
+        role: "user",
+        content: {
+            type: "text",
+            text: parts.join(""),
+        },
+    };
+    return {
+        description: PROMPT_DESCRIPTION,
+        messages: [contextMessage, requestMessage],
+    };
+}
+//# sourceMappingURL=test-planner-prompt.js.map

package/dist/agents/test-planner-prompt.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"test-planner-prompt.js","sourceRoot":"","sources":["../../src/agents/test-planner-prompt.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAGH,OAAO,EAAE,oBAAoB,EAAE,MAAM,2BAA2B,CAAC;AAEjE,MAAM,CAAC,MAAM,mBAAmB,GAAG,gBAAgB,CAAC;AAEpD,MAAM,kBAAkB,GACtB,gLAAgL,CAAC;AAEnL,MAAM,YAAY,GAAG,gBAAgB,CAAC;AAEtC;;;GAGG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAAG;IACtC;QACE,IAAI,EAAE,iBAAiB;QACvB,WAAW,EACT,oHAAoH;QACtH,QAAQ,EAAE,KAAK;KAChB;IACD;QACE,IAAI,EAAE,OAAO;QACb,WAAW,EACT,6GAA6G;QAC/G,QAAQ,EAAE,KAAK;KAChB;IACD;QACE,IAAI,EAAE,OAAO;QACb,WAAW,EACT,0FAA0F;QAC5F,QAAQ,EAAE,KAAK;KAChB;CACO,CAAC;AAEX;;GAEG;AACH,MAAM,UAAU,8BAA8B;IAC5C,OAAO;QACL,IAAI,EAAE,mBAAmB;QACzB,KAAK,EAAE,YAAY;QACnB,WAAW,EAAE,kBAAkB;QAC/B,SAAS,EAAE,CAAC,GAAG,wBAAwB,CAAC;KACzC,CAAC;AACJ,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,sBAAsB,CAAC,IAA6B;IAClE,MAAM,cAAc,GAAG,IAAI,EAAE,eAAe,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;IAC3D,MAAM,KAAK,GAAG,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;IACxC,MAAM,KAAK,GAAG,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;IAExC,MAAM,cAAc,GAAkB;QACpC,IAAI,EAAE,MAAM;QACZ,OAAO,EAAE;YACP,IAAI,EAAE,MAAM;YACZ,IAAI,EAAE,GAAG,oBAAoB;;;uRAGoP;SAClR;KACF,CAAC;IAEF,MAAM,KAAK,GAAa,CAAC,8FAA8F,CAAC,CAAC;IACzH,IAAI,cAAc;QAAE,KAAK,CAAC,IAAI,CAAC,2BAA2B,cAAc,EAAE,CAAC,CAAC;IAC5E,IAAI,KAAK;QAAE,KAAK,CAAC,IAAI,CAAC,uCAAuC,KAAK,EAAE,CAAC,CAAC;IACtE,IAAI,KAAK;QAAE,KAAK,CAAC,IAAI,CAAC,iBAAiB,KAAK,EAAE,CAAC,CAAC;IAChD,IAAI,CAAC,cAAc,IAAI,CAAC,KAAK,IAAI,CAAC,KAAK,EAAE,CAAC;QACxC,KAAK,CAAC,IAAI,CAAC,sMAAsM,CAAC,CAAC;IACrN,CAAC;IAED,MAAM,cAAc,GAAkB;QACpC,IAAI,EAAE,MAAM;QACZ,OAAO,EAAE;YACP,IAAI,EAAE,MAAM;YACZ,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;SACrB;KACF,CAAC;IAEF,OAAO;QACL,WAAW,EAAE,kBAAkB;QAC/B,QAAQ,EAAE,CAAC,cAAc,EAAE,cAAc,CAAC;KAC3C,CAAC;AACJ,CAAC"}

package/dist/api-client.d.ts

@@ -0,0 +1,52 @@
+export interface ApiClientConfig {
+    baseUrl: string;
+    apiKey?: string;
+    sessionToken?: string;
+    projectId?: string;
+}
+export interface LoginResponse {
+    success: boolean;
+    message: string;
+    data: {
+        user: {
+            id: string;
+            username: string;
+            user_email: string;
+            roles: string[];
+            permissions: string[];
+            project_roles_permissions: {
+                projectRoles: Record<string, any>;
+                consolidatedPermissions: Record<string, any>;
+            };
+            token: string;
+            org_id?: string;
+            authority_level: number;
+        };
+    };
+}
+export declare class ApiClient {
+    private client;
+    private loginClient;
+    private projectId?;
+    private cookieJar;
+    private isAuthenticated;
+    private userId?;
+    constructor(baseUrl: string, apiKey?: string, sessionToken?: string, projectId?: string);
+    setProjectId(projectId: string): void;
+    setSessionToken(token: string): void;
+    login(email: string, password: string): Promise<LoginResponse>;
+    getIsAuthenticated(): boolean;
+    /**
+     * Get cookie header string for a given URL (and optionally the API base URL).
+     * Used to forward session cookies to the automation agent WebSocket.
+     */
+    getCookieStringForUrl(url: string): Promise<string>;
+    getUserId(): string | undefined;
+    get<T = any>(url: string, config?: any): Promise<T>;
+    post<T = any>(url: string, data?: any, config?: any): Promise<T>;
+    put<T = any>(url: string, data?: any, config?: any): Promise<T>;
+    patch<T = any>(url: string, data?: any, config?: any): Promise<T>;
+    delete<T = any>(url: string, config?: any): Promise<T>;
+    postFormData<T = any>(url: string, formData: FormData, config?: any): Promise<T>;
+}
+//# sourceMappingURL=api-client.d.ts.map

package/dist/api-client.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"api-client.d.ts","sourceRoot":"","sources":["../src/api-client.ts"],"names":[],"mappings":"AAIA,MAAM,WAAW,eAAe;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,aAAa;IAC5B,OAAO,EAAE,OAAO,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE;QACJ,IAAI,EAAE;YACJ,EAAE,EAAE,MAAM,CAAC;YACX,QAAQ,EAAE,MAAM,CAAC;YACjB,UAAU,EAAE,MAAM,CAAC;YACnB,KAAK,EAAE,MAAM,EAAE,CAAC;YAChB,WAAW,EAAE,MAAM,EAAE,CAAC;YACtB,yBAAyB,EAAE;gBACzB,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;gBAClC,uBAAuB,EAAE,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;aAC9C,CAAC;YACF,KAAK,EAAE,MAAM,CAAC;YACd,MAAM,CAAC,EAAE,MAAM,CAAC;YAChB,eAAe,EAAE,MAAM,CAAC;SACzB,CAAC;KACH,CAAC;CACH;AAED,qBAAa,SAAS;IACpB,OAAO,CAAC,MAAM,CAAgB;IAC9B,OAAO,CAAC,WAAW,CAAgB;IACnC,OAAO,CAAC,SAAS,CAAC,CAAS;IAC3B,OAAO,CAAC,SAAS,CAAY;IAC7B,OAAO,CAAC,eAAe,CAAkB;IACzC,OAAO,CAAC,MAAM,CAAC,CAAS;gBAGtB,OAAO,EAAE,MAAM,EACf,MAAM,CAAC,EAAE,MAAM,EACf,YAAY,CAAC,EAAE,MAAM,EACrB,SAAS,CAAC,EAAE,MAAM;IAwJpB,YAAY,CAAC,SAAS,EAAE,MAAM;IAK9B,eAAe,CAAC,KAAK,EAAE,MAAM;IAIvB,KAAK,CAAC,KAAK,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC,aAAa,CAAC;IA4CpE,kBAAkB,IAAI,OAAO;IAI7B;;;OAGG;IACG,qBAAqB,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC;IA8BzD,SAAS,IAAI,MAAM,GAAG,SAAS;IAIzB,GAAG,CAAC,CAAC,GAAG,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,MAAM,CAAC,EAAE,GAAG,GAAG,OAAO,CAAC,CAAC,CAAC;IAKnD,IAAI,CAAC,CAAC,GAAG,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,GAAG,EAAE,MAAM,CAAC,EAAE,GAAG,GAAG,OAAO,CAAC,CAAC,CAAC;IAKhE,GAAG,CAAC,CAAC,GAAG,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,GAAG,EAAE,MAAM,CAAC,EAAE,GAAG,GAAG,OAAO,CAAC,CAAC,CAAC;IAK/D,KAAK,CAAC,CAAC,GAAG,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,GAAG,EAAE,MAAM,CAAC,EAAE,GAAG,GAAG,OAAO,CAAC,CAAC,CAAC;IAKjE,MAAM,CAAC,CAAC,GAAG,GAAG,EAAE,GAAG,EAAE,MAAM,EAAE,MAAM,CAAC,EAAE,GAAG,GAAG,OAAO,CAAC,CAAC,CAAC;IAMtD,YAAY,CAAC,CAAC,GAAG,GAAG,EACxB,GAAG,EAAE,MAAM,EACX,QAAQ,EAAE,QAAQ,EAClB,MAAM,CAAC,EAAE,GAAG,GACX,OAAO,CAAC,CAAC,CAAC;CAUd"}