Kyle Smith knksmith57
This document, SYSTEM.md, defines the external rules and constraints of the Gemini agent. It outlines the environment, available tools, and the fundamental operational mandates that govern my behavior at the system level. This is the rulebook.
You are an interactive CLI agent specializing in software engineering tasks. Your primary goal is to help users safely and efficiently, adhering strictly to the following instructions and utilizing your available tools.
- Model Constraint: My core reasoning engine is pinned to the highest-quality, generally available model family, which is currently Gemini 2.5. All my reasoning, planning, and generation tasks must use this model family to ensure consistency and quality. I am forbidden from using older model families (e.g., Gemini 1.5) unless explicitly instructed for a temporary, specific purpose. The adoption of a new, superior model family (e.g., Gemini 3.0) must be a deliberate, user-approved update to this directive.
- **Conventions:
| You are an expert software architect and project analysis assistant. Analyze the current project directory recursively and generate a comprehensive GEMINI.md file. This file will serve as a foundational context guide for any future AI model, like yourself, that interacts with this project. The goal is to ensure that future AI-generated code, analysis, and modifications are consistent with the project's established standards and architecture. | |
| + Scan and Analyze: Recursively scan the entire file and folder structure starting from the provided root directory. | |
| + Identify Key Artifacts: Pay close attention to configuration files (package.json, requirements.txt, pom.xml, Dockerfile, .eslintrc, prettierrc, etc.), READMEs, folder hierarchy, documentation files, and source code files. | |
| + Incorporate Contribution & Development Guidelines: Search for and parse any files related to development, testing, or contributions (e.g., CONTRIBUTING.md, DEVELOPMENT.md, TESTING.md). The instructions within these guides are critical |
You are conducting a retrospective analysis after completing a task. Your goal is to identify what should be captured in the context network and what adjustments need to be made to existing documentation.
Remember the distinction:
- Context Network: Planning documents, architecture decisions, design discussions, implementation strategies
The following table outlines the detailed functional requirements of The Urlist website.
| Requirement ID | Description | User Story | Expected Behavior/Outcome |
|---|---|---|---|
| FR001 | Creating a New URL List | As a user, I want to be able to start a new, empty list so I can begin adding URLs. | The system should provide a clear way for the user to initiate the creation of a new list, potentially presenting an empty list view or an "add new list" button. |
| FR002 | A |
I had some issues getting a reliable connection up. Made this after a lot of experimentation and it now works well.
Includes how to keep the connection alive when the document is not visible, handles reconnecting on errors, and also fixes certain authentication issues when coming back to a document that has not been visible while the token expired.
To use it, you pass in a factory function for your RealtimeChannel. Do not call .subscribe() on the channel, the handler will do this for you. See example.
PS: If you're not using supabase-js you'll need to change stuff a bit. Instead of passing in SupabaseClient switch it to use RealtimeClient, and update the refreshSessionIfNeeded method to your authentication implementation.
If you see any problems or have suggestions for improvements, please leave a comment.
| import { ConfigContext } from '@expo/config'; | |
| // eslint-disable-next-line no-console | |
| // console.log('ENV', process.env); | |
| // expands type in the vscode tooltip. | |
| type ExpandTooltip<T> = T extends infer O ? { [K in keyof O]: O[K] } : never; | |
| const EXPO_SDK = '51'; | |
| const BINARY_ITERATION_FOR_SDK = '1'; // start with 1. CAN NOT BE 0. |
| import type { FetchResult, Operation } from "@apollo/client"; | |
| import { Observable } from "@apollo/client"; | |
| import { MockLink } from "@apollo/client/testing"; | |
| import type { Observer } from "@apollo/client/utilities"; | |
| // Apollo Client's out of the box utilities for testing subscriptions are limited: | |
| // - The `mocks` argument provided to Apollo's `MockedProvider` is only capable of mocking a | |
| // single subscription payload per subscription. | |
| // - Apollo's `MockSubscriptionLink` can be used to mock multiple subscription payloads via | |
| // a `simulateResult` method. However, the `simulateResult` method delivers data to _every_ |