diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md deleted file mode 100644 index d3b9108..0000000 --- a/.github/copilot-instructions.md +++ /dev/null @@ -1,77 +0,0 @@ -# Instructions - -In this file i'm providing instructions for GitHub Copilot on how to assist me while coding in this project. - -## Context -Read the .system/constants.md - -## Available Skills - -This project has reusable skills that can be invoked by agents to perform common tasks. Load the skills from the `.system/skills/`. - -## Custom Commands - -This project uses custom agent commands to streamline feature development and planning. If a prompt starts with one of the commands below, Copilot should load the corresponding agent from the `.system/agents/` directory and execute its workflow. - -### @Vi - Analyst Agent (Planning) -**Command:** `@Vi ` - -**Purpose:** Loads the analyst agent from `.system/agents/analyst.md` to create a comprehensive execution plan for a given feature request. - -**What it does:** -- Analyzes the feature request -- Creates a detailed execution plan with user stories -- Documents acceptance criteria and technical specifications -- Identifies dependencies and risk assessment -- Generates a PLAN_FILE at `docs/plans/.md` - -**Example Usage:** -``` -@Vi Add a new enemy type that shoots homing missiles with adaptive difficulty scaling -``` - -**Workflow:** Always use @Vi first when you want to plan a complex feature or enhancement. - ---- - -### @dev - Developer Agent (Implementation) -**Command:** `@dev ` - -**Purpose:** Loads the developer agent from `.system/agents/developer.md` to implement the execution plan created by @Vi and deliver production-ready code. - -**What it does:** -- Reads the PLAN_FILE from `docs/plans/.md` -- Creates a feature branch for isolated development -- Implements each story with code, testing, and documentation -- Verifies implementation against original requirements -- Generates an OUTCOME_FILE at `docs/outcomes/.md` - -**Parameters:** -- ``: The outcome name in the format used in the PLAN_FILE (e.g., "FirstPersonSpaceShooter", "EnhancedGameplayFeatures") - -**Example Usage:** -``` -@dev EnhancedGameplayFeatures -``` - -**Workflow:** Use @dev after @Vi has created a PLAN_FILE. The outcome_name should match the PLAN_FILE name in `docs/plans/`. - ---- - -## Development Workflow - -1. **Planning Phase:** Use `@Vi ` to create a plan -2. **Implementation Phase:** Use `@dev ` to implement the plan -3. **Review:** Review the generated pull request and test results -4. **Merge:** Merge the feature branch when approved - ---- - -## Project Structure References - -- **Plans:** `docs/plans/.md` -- **Outcomes:** `docs/outcomes/.md` -- **Agents:** `.system/agents/` - - `analyst.md` - Planning and analysis agent - - `developer.md` - Implementation and delivery agent -- **Constants:** `.system/constants.md` - Project path and variable definitions \ No newline at end of file diff --git a/.gitignore b/.gitignore index 02025f9..c7cf5f8 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,6 @@ vite.config.js.timestamp-* vite.config.ts.timestamp-* debug_page.txt +.github/agents/ +.github/schemas/ +.github/skills/ \ No newline at end of file diff --git a/.system/abstract_architecture.md b/.system/abstract_architecture.md deleted file mode 100644 index 53762c0..0000000 --- a/.system/abstract_architecture.md +++ /dev/null @@ -1,174 +0,0 @@ -# Hexagonal Architecture (Ports & Adapters) – Reference Manual - -## Overview - -Hexagonal Architecture, also known as **Ports and Adapters**, is a software design pattern that isolates an application’s **core business logic** from external systems such as user interfaces, databases, frameworks, and third-party services. - -The application is conceptually placed at the center (often drawn as a hexagon). All communication with the outside world happens through **ports** (abstract interfaces), which are implemented by **adapters**. - -The key idea: -> **The domain does not depend on technology. Technology depends on the domain.** - ---- - -## Fundamental Principles - -### 1. Business Logic First -The core domain represents the real business rules and use cases. It must: -- Be independent of UI, databases, frameworks, and delivery mechanisms -- Express *what* the system does, not *how* it is delivered - -### 2. Explicit Boundaries -All interactions between the core and external systems cross explicit boundaries (ports). This prevents accidental coupling. - -### 3. Dependency Inversion -Dependencies always point **inward**, toward the core. External components depend on abstractions defined by the core. - ---- - -## Core Concepts - -### Domain (Core) -The domain contains: -- Business entities -- Value objects -- Use cases / application services -- Domain rules and policies - -It contains **no technical concerns** such as HTTP, databases, file systems, or frameworks. - ---- - -### Port -A **port** is an abstract interface defined by the core. - -Ports describe: -- What the application *needs* from the outside world (output ports) -- What the application *offers* to the outside world (input ports) - -Ports are defined in the language of the domain, not infrastructure. - -Examples (conceptual): -- “Store an order” -- “Send a notification” -- “Execute a checkout use case” - ---- - -### Adapter -An **adapter** is a concrete implementation of a port using a specific technology. - -Adapters translate: -- External representations → domain concepts -- Domain requests → external system calls - -Adapters are replaceable and exist at the system’s edge. - -#### Adapter Types - -**Primary (Driving) Adapters** -- Initiate interaction with the core -- Examples: Web UI, CLI, REST controller, automated tests - -**Secondary (Driven) Adapters** -- Are used by the core -- Examples: Database repositories, message brokers, email services - ---- - -## Dependency Rule - -- The **core defines ports** -- **Adapters implement ports** -- The core knows nothing about adapters -- Adapters depend on the core, never the reverse - -This rule guarantees that business logic remains stable even when technologies change. - ---- - -## Interaction Flow - -1. A primary adapter receives input (e.g., user action) -2. It calls an **input port** -3. The core executes business logic -4. The core calls **output ports** as needed -5. Secondary adapters fulfill those ports using external systems - -All I/O stays outside the core. - ---- - -## Structuring a System - -A conceptual structure: - -- Core - - Domain entities - - Use cases - - Port interfaces -- Adapters - - Input adapters (UI, API, tests) - - Output adapters (DB, services, files) -- Composition root - - Wires ports to adapters at startup - -This structure is conceptual, not tied to folders or modules. - ---- - -## Testing Strategy - -Hexagonal architecture enables strong testing practices: - -- Test core logic using fake or in-memory adapters -- No need for databases or servers in unit tests -- Integration tests focus on individual adapters - -Testing becomes simpler because dependencies are explicit and replaceable. - ---- - -## Benefits - -- High testability -- Clear separation of concerns -- Technology independence -- Easier maintenance and evolution -- Multiple interfaces over the same core logic -- Strong alignment with Domain-Driven Design - ---- - -## Comparison to Layered Architecture - -Layered Architecture: -- Organizes code by technical layers -- Often allows UI → DB coupling -- Business logic can leak into infrastructure - -Hexagonal Architecture: -- Organizes around the domain -- Enforces strict boundaries -- Treats UI and DB as interchangeable details - ---- - -## When to Use - -Hexagonal architecture is well suited for: -- Medium to large systems -- Long-lived codebases -- Complex business domains -- Systems with multiple interfaces -- Applications that must remain adaptable - -It may be unnecessary for very small or trivial applications. - ---- - -## Summary - -Hexagonal Architecture places the domain at the center and treats all external systems as replaceable plugins. By communicating exclusively through ports and adapters, it ensures long-term flexibility, maintainability, and testability. - -This pattern is language-agnostic and focuses on **design principles**, not frameworks. diff --git a/.system/agents/analyst.md b/.system/agents/analyst.md deleted file mode 100644 index 80e589a..0000000 --- a/.system/agents/analyst.md +++ /dev/null @@ -1,37 +0,0 @@ -# Analyst - -You are a senior software engineer covering the analyst role. -Your task is to produce a comprehensive execution plan, enriched with technical documentation and examples given a `USER_PROMPT` - -## Variables -- USER_PROMPT: the prompt from the user -- OUTCOME_NAME: a 4 words summary of what the user wants to achieve -- PLAN_FILE: ${DOCS_DIR}/plans/${OUTCOME_NAME} - -## Workflow - -1. Create a mental context of the application state - 1. check the existing files - 2. check the git status - 3. check the recent commits - 4. **Perform a Cross-Reference Check:** use tools to find "hidden" dependencies (database schemas, event listeners, or shared state) that relate to the requested changes. -2. Analyze and decompose the ${USER_PROMPT} into the smallest unit of work possible -> stories -3. loop over stories: - -1. **Use sequential-thinking** to provide a draft implementation plan that will respect your instructions. Specifically, analyze the **blast radius** of the story to identify if modifying a module impacts distant components or data contracts. -2. check your draft against the current application state - if not applicable go back to step 1 -2. check your draft against the documentation - if not applicable go back to step 1 -3. Verify that your draft is applicable to the current application context AND respects your instructions, if yes update the ${PLAN_FILE}, else go back to step 1. -4. Update your mental context of the application state with the new solution - - -## Instructions -- Your solutions must respect the principle of the abstract architecture: read the file in $SYS_DIR/abstract_architecture.md -- **Map the Side Effects:** You must look beyond direct file imports. If a story modifies a data structure or an API, you MUST identify all consumers (Events, DB, UI State) and include them in the ${PLAN_FILE}. -- Discard your previous knowledge of the language or framework as it is most likely outdated. ALWAYS check the documentation using the tools provided to you. -- Your solutions must be idiomatic of the current version of the language or framework you are using: always fetch the documentation and check against it. -- It's not your job to execute the plan. Once the ${PLAN_FILE} is created report it to the user and STOP. - -## Report - -Notify the user of the creation of ${PLAN_FILE}. Summarize the "Blast Radius" (the modules and hidden dependencies affected) so the developer is aware of the side effects. \ No newline at end of file diff --git a/.system/agents/developer.md b/.system/agents/developer.md deleted file mode 100644 index 9a22023..0000000 --- a/.system/agents/developer.md +++ /dev/null @@ -1,115 +0,0 @@ -# Developer - -You are a senior software engineer covering the developer role. -Your task is to implement the comprehensive execution plan provided by the analyst and deliver production-ready code. - -## Variables -- OUTCOME_NAME: a 4 words summary of what needs to be achieved -- PLAN_FILE: the execution plan created by the analyst (typically ${DOCS_DIR}/plans/${OUTCOME_NAME}) -- OUTCOME_FILE: the implementation report file (${DOCS_DIR}/outcomes/${OUTCOME_NAME}.md) -- FEATURE_BRANCH: a git branch created for this work -- CODE_REVIEW_CHECKLIST: verification steps before marking work as complete -- SIDE_EFFECT_GRAPH: a mental or documented map of all modules and data flows impacted by a change - -## Pre-Workflow Validation - -**STOP and notify the user if ANY of the following conditions are met:** -1. No OUTCOME_NAME has been provided -2. OUTCOME_NAME cannot be determined from the context -3. The PLAN_FILE does not exist or cannot be accessed -4. The PLAN_FILE does not contain a valid execution plan - -If any of these conditions exist, ask the user to either: -- Provide the OUTCOME_NAME explicitly -- Load the analyst agent first to generate the execution plan -- Provide additional context to determine the OUTCOME_NAME - -## Workflow - -1. Setup implementation environment - 1. read the PLAN_FILE thoroughly - 2. if you are implementing a new feature and you are not already in a feature branch create a feature branch from the current master/main/dev branch, else if you aren't on master/main/dev branch and you are developing a fix continue working on the current branch - 3. verify understanding of requirements and dependencies -2. **Map the Blast Radius (Side Effect Analysis)** - 1. identify all files, functions, and database schemas that will be touched - 2. **Search the codebase** for all references (imports, calls, API consumers) of the code being modified - 3. create a mental or scratchpad "SIDE_EFFECT_GRAPH" to identify potential breaking changes in distant modules -3. Implement the solution - 1. for each story in PLAN_FILE: - 1. **Use sequential-thinking to analyze the story:** - - Break down the story into smallest implementable units - - **Identify potential architecture conflicts and side effects** - - Determine version-specific and idiomatic approach - - Research latest documentation for all technologies involved - 2. **Fetch official documentation for all frameworks/libraries used:** - - Do NOT rely on previous knowledge - - Check for version-specific best practices - - Identify any deprecated patterns or new idiomatic approaches - - Verify API availability in current versions - 3. implement the code changes according to the plan and documented best practices - 4. run relevant tests and validation - 5. commit changes with clear messages (include documentation verification) - 6. update documentation if needed -4. Verify implementation quality - 1. check code against project standards - 2. validate code matches current version documentation patterns - 3. run full test suite (including modules identified in the SIDE_EFFECT_GRAPH) - 4. validate against original requirements - 5. ensure no regressions or breaking changes -5. Prepare for review - 1. create a pull request with clear description - 2. link to the original PLAN_FILE - 3. provide testing evidence - 4. highlight all documentation sources checked during implementation - 5. document any deviations from the plan with rationale and documentation references - -## Instructions -- **Always use sequential-thinking when:** - - Facing complex implementation decisions - - Uncertain about the best approach for a story - - Need to make architectural choices that could impact the codebase - - Troubleshooting unexpected behavior or conflicts - - Deciding between multiple implementation patterns -- **Trace Side Effects:** Before modifying any function or component, you MUST find all its usages in the codebase. Do not assume a change is isolated. -- **Discard all previous knowledge** about frameworks and languages you have -- **Always fetch and verify official documentation** for: - - The specific version of the framework/language being used - - All third-party libraries and dependencies - - Any API or pattern you're about to use - - Best practices and idiomatic patterns for the current version - - Check your skills for appropriate documentation searching skill and use them. -- Your code must respect the principle of the abstract architecture: read the file in $SYS_DIR/abstract_architecture.md -- Write idiomatic, version-specific code that matches current official documentation patterns -- Ensure all code is tested before submission -- Maintain backwards compatibility unless explicitly breaking changes are approved -- Keep commits atomic and focused with descriptive messages -- Update relevant documentation, comments, and type definitions with references to official docs -- Ask for clarification if any part of the plan is ambiguous or conflicts with current architecture - -## Code Review Checklist -- [ ] All tests pass (unit, integration, e2e) -- [ ] **Side Effects identified and mitigated (Blast Radius check)** -- [ ] Code follows project style guide and patterns -- [ ] Code matches current version documentation patterns and idioms -- [ ] Documentation is complete and accurate -- [ ] All implementation decisions have been verified against official documentation -- [ ] No console errors or warnings -- [ ] Git history is clean with descriptive commits -- [ ] Changes are aligned with the PLAN_FILE -- [ ] No breaking changes to public APIs (unless intentional) -- [ ] Performance impact is acceptable -- [ ] Previous knowledge was not relied upon - all patterns verified against docs - -## Report - -Upon completion of implementation: -1. Create or update the OUTCOME_FILE at docs/outcomes/${OUTCOME_NAME}.md with: - 1. Summary of successful completion - 2. Feature branch and pull request information - 3. List of all commits made - 4. Testing results summary - 5. **Impact Summary:** List any modules or components affected by side effects and how they were verified - 6. Any deviations from the original plan with rationale - 7. Links to PLAN_FILE and PR -2. Notify the user with a reference to the OUTCOME_FILE -3. Provide a brief summary of what was completed \ No newline at end of file diff --git a/.system/constants.md b/.system/constants.md deleted file mode 100644 index 7e53f18..0000000 --- a/.system/constants.md +++ /dev/null @@ -1,6 +0,0 @@ -# Constants - -Provides definition for constant variables or expressions - -- SYS_DIR: `./.system` -- DOCS_DIR: `./docs` \ No newline at end of file diff --git a/.system/skills/finalize_branch.md b/.system/skills/finalize_branch.md deleted file mode 100644 index db9672d..0000000 --- a/.system/skills/finalize_branch.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -name: finalize_branch -description: squashes all commits on current branch, merges to main and deletes current branch ---- - -# Finalize Branch Skill - -This skill is used to finish work on a feature by squashing all commits on the current branch into a single commit, merging it into main, and deleting the feature branch. It includes comprehensive edge case handling. - -## Prerequisites - -- Git repository initialized -- Commits made on current feature branch -- Current branch is NOT main -- All work is committed (no uncommitted changes) -- Main branch exists - -## Pre-Execution Checks - -Before proceeding with the finalization workflow, verify these conditions: - -### 1. Check Current Branch -```bash -git rev-parse --abbrev-ref HEAD -``` -**Edge Case:** If the output is `main`, abort with error: "Already on main branch. Cannot finalize main branch." - -### 2. Check for Uncommitted Changes -```bash -git status --porcelain -``` -**Edge Case:** If output is non-empty, abort with error: "Uncommitted changes detected. Commit or stash changes before finalizing branch." - -### 3. Check for Commits to Squash -```bash -git rev-list --count main..HEAD -``` -**Edge Case:** If count is 0, abort with error: "No new commits on current branch to squash. Nothing to finalize." - -### 4. Verify Main Branch Exists -```bash -git rev-parse --verify main -``` -**Edge Case:** If command fails, abort with error: "Main branch does not exist. Cannot merge into non-existent branch." - -## Finalization Workflow - -### Step 1: Fetch Latest Changes -```bash -git fetch origin -``` -**Purpose:** Ensure you have the latest main branch from remote -**Edge Case Handling:** If fetch fails, log warning but continue (local merge may still work) - -### Step 2: Check for Merge Conflicts -```bash -git merge-base --is-ancestor main HEAD -``` -**Edge Case:** If this returns false, main has commits not in current branch: -- Run: `git rebase origin/main` -- If rebase fails with conflicts, abort and inform: "Rebase conflicts detected. Resolve conflicts manually before retrying finalization." - -### Step 3: Squash All Commits -```bash -git reset --soft main -``` -**Purpose:** Moves all changes to staging area, keeping files intact -**Verification:** Run `git status` to confirm all files are staged - -### Step 4: Create Squashed Commit -```bash -git commit -m "" -``` -**Edge Cases:** -- If commit fails with "nothing to commit", abort: "No changes to commit after squash operation." -- Use descriptive commit message based on branch name or feature implemented - -### Step 5: Switch to Main Branch -```bash -git checkout main -``` -**Edge Case:** If checkout fails, abort: "Failed to switch to main branch. Branch may be locked or have other issues." - -### Step 6: Pull Latest Main (Final Check) -```bash -git pull origin main -``` -**Edge Case Handling:** -- If pull shows merge conflicts, abort: "Merge conflicts on main branch. Resolve manually before retrying." -- If pull is already up-to-date, continue normally - -### Step 7: Merge Feature Branch -```bash -git merge -``` -**Edge Cases:** -- If merge fails with conflicts: - - Abort merge: `git merge --abort` - - Return error: "Merge conflicts detected. Resolve manually and retry finalization." -- If merge fails with other error, abort and investigate - -### Step 8: Push to Remote -```bash -git push origin main -``` -**Edge Cases:** -- If push is rejected (force pull needed): Abort and inform: "Main branch has remote changes. Run 'git pull origin main' and retry." -- If push fails due to permissions: Abort with: "Permission denied pushing to main. Check git credentials and permissions." - -### Step 9: Delete Local Feature Branch -```bash -git branch -d -``` -**Edge Case:** If deletion fails (branch not fully merged), use force deletion: -```bash -git branch -D -``` -**Warning:** Only force delete if Step 7 merge succeeded. - -### Step 10: Delete Remote Feature Branch (if exists) -```bash -git push origin --delete -``` -**Edge Cases:** -- If branch doesn't exist on remote, continue normally -- If deletion fails due to permissions, log warning but consider success (local cleanup done) - -## Rollback Procedure - -If any step fails, execute rollback: - -```bash -# Return to feature branch if on main -git checkout - -# Reset to pre-squash state if already squashed -git reset --hard -``` - -**Important:** Save the original branch commit SHA before beginning squash operation for rollback capability. - -## Success Criteria - -✅ All checks passed -✅ Commits squashed into single commit -✅ Feature branch merged into main -✅ New commit pushed to remote -✅ Feature branch deleted locally and remotely -✅ Currently on main branch with latest changes - -## Error Handling Summary - -| Error | Action | -|-------|--------| -| Already on main | Abort, inform user | -| Uncommitted changes | Abort, instruct commit/stash | -| No commits to squash | Abort, inform no changes | -| Merge conflicts | Abort, instruct manual resolution | -| Push rejected | Abort, pull latest and retry | -| Permission errors | Abort, check git credentials | -| Remote branch missing | Continue (non-fatal) | - -## Logging Requirements - -Log all executed commands and their outputs for audit trail and debugging purposes. diff --git a/.system/skills/sveltekit_documentation.md b/.system/skills/sveltekit_documentation.md deleted file mode 100644 index ed6262e..0000000 --- a/.system/skills/sveltekit_documentation.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -name: sveltekit-documentation -description: provides the steps to fetch the sveltekit documentation ---- - -# SvelteKit Documentation skill - -This skill is used to fetch the latest sveltekit documentation from the llms.txt endpoints. - -## Workflow -**Call get-single-web-page-content** with this url: https://svelte.dev/llms-full.txt. \ No newline at end of file diff --git a/package-lock.json b/package-lock.json index 4f287b0..f35be1c 100644 --- a/package-lock.json +++ b/package-lock.json @@ -910,18 +910,6 @@ "node": ">=6.0.0" } }, - "node_modules/@jridgewell/source-map": { - "version": "0.3.11", - "resolved": "https://registry.npmjs.org/@jridgewell/source-map/-/source-map-0.3.11.tgz", - "integrity": "sha512-ZMp1V8ZFcPG5dIWnQLr3NSI1MiCU7UETdS/A0G8V/XWHvJv3ZsFqutJn1Y5RPmAPX6F3BiE397OqveU/9NCuIA==", - "dev": true, - "license": "MIT", - "optional": true, - "dependencies": { - "@jridgewell/gen-mapping": "^0.3.5", - "@jridgewell/trace-mapping": "^0.3.25" - } - }, "node_modules/@jridgewell/sourcemap-codec": { "version": "1.5.5", "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.5.tgz", @@ -2449,14 +2437,6 @@ "node": ">=8" } }, - "node_modules/buffer-from": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", - "integrity": "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==", - "dev": true, - "license": "MIT", - "optional": true - }, "node_modules/call-bind-apply-helpers": { "version": "1.0.2", "resolved": "https://registry.npmjs.org/call-bind-apply-helpers/-/call-bind-apply-helpers-1.0.2.tgz", @@ -2565,14 +2545,6 @@ "node": ">= 0.8" } }, - "node_modules/commander": { - "version": "2.20.3", - "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz", - "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==", - "dev": true, - "license": "MIT", - "optional": true - }, "node_modules/commondir": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/commondir/-/commondir-1.0.1.tgz", @@ -5140,29 +5112,6 @@ "node": ">=0.10.0" } }, - "node_modules/source-map-support": { - "version": "0.5.21", - "resolved": "https://registry.npmjs.org/source-map-support/-/source-map-support-0.5.21.tgz", - "integrity": "sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w==", - "dev": true, - "license": "MIT", - "optional": true, - "dependencies": { - "buffer-from": "^1.0.0", - "source-map": "^0.6.0" - } - }, - "node_modules/source-map-support/node_modules/source-map": { - "version": "0.6.1", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz", - "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==", - "dev": true, - "license": "BSD-3-Clause", - "optional": true, - "engines": { - "node": ">=0.10.0" - } - }, "node_modules/stackback": { "version": "0.0.2", "resolved": "https://registry.npmjs.org/stackback/-/stackback-0.0.2.tgz", diff --git a/scripts/gen-auth.js b/scripts/gen-auth.js index cf404d8..9dfa8a3 100644 --- a/scripts/gen-auth.js +++ b/scripts/gen-auth.js @@ -1,3 +1,4 @@ +#!/usr/bin/env node import { chromium } from 'playwright'; import fs from 'fs'; import path from 'path'; diff --git a/secrets/auth.json b/secrets/auth.json index 5b98671..45b8f35 100644 --- a/secrets/auth.json +++ b/secrets/auth.json @@ -5,7 +5,7 @@ "value": "SDRORLyWEsWWty2ZoVGdER", "domain": ".instagram.com", "path": "/", - "expires": 1800972720.924086, + "expires": 1805679336.753547, "httpOnly": false, "secure": true, "sameSite": "Lax" @@ -45,21 +45,11 @@ "value": "59661903731", "domain": ".instagram.com", "path": "/", - "expires": 1774188720.924166, + "expires": 1778895336.753668, "httpOnly": false, "secure": true, "sameSite": "None" }, - { - "name": "wd", - "value": "1280x720", - "domain": ".instagram.com", - "path": "/", - "expires": 1767017521, - "httpOnly": false, - "secure": true, - "sameSite": "Lax" - }, { "name": "sessionid", "value": "59661903731%3AbekaIlo4nn7x2n%3A29%3AAYhv1LJUsfRtBSH-WmDLVrxiM7T9UotIOM3XY3iHKQ", @@ -72,13 +62,23 @@ }, { "name": "rur", - "value": "\"CLN\\05459661903731\\0541797948720:01fe633f4b589d8aecb8b5e77985c6d725d42e9808fd112b123a1597ecfb04ee655ee7ff\"", + "value": "\"CLN\\05459661903731\\0541802655336:01feb1b7e2710ac48e6833d9c5ea2ec2780a10752766110266c6865bb13b99965b41753b\"", "domain": ".instagram.com", "path": "/", "expires": -1, "httpOnly": true, "secure": true, "sameSite": "Lax" + }, + { + "name": "wd", + "value": "1280x720", + "domain": ".instagram.com", + "path": "/", + "expires": 1771724138, + "httpOnly": false, + "secure": true, + "sameSite": "Lax" } ], "origins": [ @@ -87,15 +87,15 @@ "localStorage": [ { "name": "chatd-deviceid", - "value": "d559760a-86d0-43be-97d2-f15ab465ed32" + "value": "44fa3b1b-c2d0-4356-9a64-133d971a1c45" }, { "name": "hb_timestamp", - "value": "1766412721948" + "value": "1771119338970" }, { "name": "IGSession", - "value": "wqqxv4:1766414521986" + "value": "53laur:1771121139044" }, { "name": "pixel_fire_ts", @@ -103,19 +103,23 @@ }, { "name": "signal_flush_timestamp", - "value": "1766412721967" + "value": "1771119338992" }, { "name": "Session", - "value": "p2abeh:1766412756986" + "value": "k3dql4:1771119374044" }, { "name": "has_interop_upgraded", "value": "{\"lastCheckedAt\":1766366944051,\"status\":false}" }, + { + "name": "ig_boost_on_web_campaign_upsell_shown", + "value": "false" + }, { "name": "banzai:last_storage_flush", - "value": "1766412720586.5" + "value": "1771119337751.8" } ] }