mozempk/insta-recipe
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new agents

Browse Source
This commit is contained in:
Giancarmine Salucci
2026-02-15 02:41:07 +01:00
parent e49dbfae41
commit cc8d46660a
11 changed files with 27 additions and 655 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
.github/copilot-instructions.md vendored
View File

@@ -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 <feature description>`
**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/<outcome-name>.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 <outcome_name>`
**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/<outcome-name>.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/<outcome-name>.md`
**Parameters:**
- `<outcome_name>`: 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 <feature description>` to create a plan
2. **Implementation Phase:** Use `@dev <outcome_name>` 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/<outcome-name>.md`
- **Outcomes:** `docs/outcomes/<outcome-name>.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

3
.gitignore vendored
View File

@@ -26,3 +26,6 @@ vite.config.js.timestamp-*
vite.config.ts.timestamp-*
debug_page.txt
.github/agents/
.github/schemas/
.github/skills/

174
.system/abstract_architecture.md
View File

@@ -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.

37
.system/agents/analyst.md
View File

@@ -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:
<story-loop>
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
</story-loop>
## 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.

115
.system/agents/developer.md
View File

@@ -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

6
.system/constants.md
View File

@@ -1,6 +0,0 @@
# Constants
Provides definition for constant variables or expressions
- SYS_DIR: `./.system`
- DOCS_DIR: `./docs`

165
.system/skills/finalize_branch.md
View File

@@ -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 "<commit-message>"
```
**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 <feature-branch-name>
```
**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 <feature-branch-name>
```
**Edge Case:** If deletion fails (branch not fully merged), use force deletion:
```bash
git branch -D <feature-branch-name>
```
**Warning:** Only force delete if Step 7 merge succeeded.
### Step 10: Delete Remote Feature Branch (if exists)
```bash
git push origin --delete <feature-branch-name>
```
**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 <feature-branch-name>
# Reset to pre-squash state if already squashed
git reset --hard <original-commit-before-squash>
```
**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.

11
.system/skills/sveltekit_documentation.md
View File

@@ -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.

51
package-lock.json generated
View File

@@ -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",

1
scripts/gen-auth.js
View File

@@ -1,3 +1,4 @@
#!/usr/bin/env node
import { chromium } from 'playwright';
import fs from 'fs';
import path from 'path';

42
secrets/auth.json
View File

@@ -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"
}
]
}