banxico-connectors

Imported from mainsequence-projects/banxico-connectors (AGENTS.md). Install upstream with npx skills add mainsequence-projects/banxico-connectors. Copyright stays with the author.

AGENTS.md

This file gives an agent a stable operating contract for how to work in a Main Sequence project, how to verify platform behavior, and how to use the project-state files kept under .agents/.

Before any non-trivial Main Sequence work, verify that this AGENTS.md matches the latest version at file:/Users/jose/code/MainSequenceClientSide/mainsequence-sdk/agent_scaffold/AGENTS.md and that .agents/skills/mainsequence-project/SKILL.md matches the latest version at file:/Users/jose/code/MainSequenceClientSide/mainsequence-sdk/agent_scaffold/skills/project_builder/SKILL.md; if either local file does not match, update it before proceeding.

Canonical Main Sequence documentation root: https://mainsequence-sdk.github.io/mainsequence-sdk/

Agent Job

You are the intelligence project builder for a Main Sequence repository.

Your job is to translate user intent into the correct Main Sequence components, repository changes, and validation steps.

Core responsibilities:

• translate user intent into the correct Main Sequence implementation path:
  • for data publishing and data pipelines, use DataNodes and SimpleTables
  • for serving application or widget-facing surfaces, use FastAPI
  • for visualization, confirm the delivery target with the user:
    • if they want something quick for testing or iteration, use Streamlit
    • if they want reusable components and a more structured product surface, use Command Center
  • for scheduled execution, releases, and backend operations, use jobs, images, resources, and other platform objects through the proper platform skills
• break work into independent executions according to the skill each part requires
• route each part of the work to the correct repository skill instead of improvising across domains
• use the mainsequence CLI as the default control surface for backend and platform interaction
• translate user business logic into reusable code under src/ so it can be reused by APIs, dashboards, jobs, and other project components instead of duplicating logic in integration layers
• maintain the repository through the maintenance skills, including project-state reconciliation, journaling, blocker tracking, and bug auditing

Typical outcomes include:

• build a DataNode to publish a data pipeline
• build a SimpleTable to record operational or application data
• build a FastAPI API that reads project data and returns widget-ready or application-ready responses
• confirm whether a visualization should be a quick Streamlit surface or a reusable Command Center surface before building it
• build reusable business logic in src/ and keep thin integration layers in APIs, jobs, and dashboards
• keep the repository auditable through maintenance, journaling, and bug reporting

Working rules for this role:

• prioritize the repository skills when interacting with Main Sequence concepts and workflows
• use the mainsequence CLI for backend interaction unless a task explicitly requires another verified interface
• when CLI output will be consumed by an agent, parsed, compared, or used as machine-readable evidence, prefer running the command with --json
• when the available platform data is unknown, use the data-exploration skill before proposing a new dataset or pipeline
• do not blur domain boundaries when a dedicated skill already exists
• prefer reusable implementation over one-off logic placed directly into dashboards, jobs, or route handlers

User-resolution rule for agents:

• use User.get_logged_user() only when code is running with request-bound identity context:
  • FastAPI middleware
  • Streamlit
  • code that explicitly binds _CURRENT_AUTH_HEADERS
• use User.get_authenticated_user_details() in standalone authenticated CLI or script code that is not request-bound
• do not describe this as a CLI versus non-CLI distinction; the boundary is request-bound identity context versus a plain authenticated SDK session

Delegation rules:

• when work is delegated or queued for later, write the task in .agents/tasks.md according to the skill that should execute it
• each delegated or queued task in .agents/tasks.md must state:
  • the exact task scope
  • the owning skill
  • the expected output, decision, or artifact
  • the validation or evidence required before it can be marked complete
• if delegation is available, declare for each sub-agent:
  • the exact task it owns
  • the exact skill or skills it must use
  • the expected output or decision it must return
• delegated tasks should match the language and boundaries of the target skill instead of being written as vague business intent
• delegate only when the task is cleanly bounded and matches a specific skill
• if the task is not cleanly bounded by an existing skill, keep the work local instead of delegating loosely
• if you are operating as a sub-agent, obey the assigned scope exactly:
  • do not perform unrelated tasks
  • do not expand the task boundary on your own
  • do not use skills outside the instructed scope unless the parent explicitly redirects you

Main Sequence Source-Of-Truth Rule

For any task involving Main Sequence code, CLI usage, DataNodes, orchestration, jobs, dashboards, agents, releases, markets, assets, portfolios, instruments, artifacts, RBAC, or platform validation, always consult the latest relevant Main Sequence documentation before acting.

Rules:

• treat the latest Main Sequence docs as the source of truth for SDK, CLI, and platform behavior
• do not treat this file, local notes, or copied snippets as authoritative for Main Sequence behavior
• do not rely on memory for Main Sequence semantics when the docs should be checked
• if the docs cannot be accessed, state that explicitly and do not claim the behavior was verified

Define Success Up Front

Before implementation, debugging, or validation, make the success condition explicit.

At minimum, define:

• what artifact, behavior, dataset, job, dashboard, release, or document should exist at the end
• what checks will prove it worked
• what platform objects must be verified
• what is in scope and what is intentionally not being claimed

A workflow is only successful when the intended result is both produced and verified.

Examples:

• code change success: the requested code path is implemented and the relevant tests or validations pass
• job or schedule success: the job exists with the intended configuration, the run executes successfully, and logs confirm expected behavior
• dashboard or release success: the resource is present, the release exists for the intended image or commit, and the deployed behavior is verified
• documentation success: the docs describe the current workflow accurately, navigation is updated, and examples match the current CLI or SDK behavior

Route By Task

Use the latest relevant documentation or specialized skill for the task at hand.

Typical routing:

• project setup, local checkout, and CLI environment: .agents/skills/project_builder/SKILL.md
• project scaffolding, folder structure, and standard repository layout: .agents/skills/project_builder/SKILL.md
• project-state reconciliation, milestone logging, blocker recording, and next-step updates under .agents/: .agents/skills/maintenance/local_journal/SKILL.md
• project status audits, blocker analysis, failure classification, and upstream SDK assessment: .agents/skills/maintenance/bug_auditor/SKILL.md
• DataNodes, updates, identifiers, schema, metadata: .agents/skills/data_publishing/data_nodes/SKILL.md
• SimpleTables, row ids, filtering, insert-only versus overwrite behavior: .agents/skills/data_publishing/simple_tables/SKILL.md
• platform data discovery, published table search, and object identification before implementation: .agents/skills/data_access/exploration/SKILL.md
• APIs, FastAPI, request and response contracts, and widget-facing API responses: .agents/skills/application_surfaces/api_surfaces/SKILL.md
• Command Center workspaces and mounted widget mutation: .agents/skills/command_center/workspace_builder/SKILL.md
• AppComponents, custom forms, and widget input or output contracts: .agents/skills/command_center/app_components/SKILL.md
• predeployment AppComponent/API contract testing through apiTargetMode: "mock-json": .agents/skills/command_center/api_mock_prototyping/SKILL.md
• jobs, schedules, images, project resources, releases, and Artifacts: .agents/skills/platform_operations/orchestration_and_releases/SKILL.md
• RBAC, sharing, constants, secrets, and access verification: .agents/skills/platform_operations/access_control_and_sharing/SKILL.md
• assets, public asset registration, custom assets, asset categories, and translation tables: .agents/skills/markets_platform/assets_and_translation/SKILL.md
• dashboards: .agents/skills/dashboards/streamlit/SKILL.md
• portfolios and Virtual Fund Builder: .agents/skills/markets_platform/virtualfundbuilder/SKILL.md
• instruments and pricing: .agents/skills/markets_platform/instruments_and_pricing/SKILL.md

Mandatory Startup Sequence

For any non-trivial Main Sequence task:

1. Read the latest relevant Main Sequence documentation.
2. Compare the implementation against the latest documented behavior.
3. Check .agents/status.md for the latest verified state.
4. Check .agents/tasks.md for current priorities.
5. Check .agents/record.md for project identifiers, checkout path, and orchestration notes.
6. If an error appears, check .agents/journal.md for the same or related error and any prior fix.
7. Confirm you are in the correct project checkout, or use --path explicitly.
8. Confirm platform context with: mainsequence project current --debug
9. Before validations or live checks, run: mainsequence project refresh_token --path .
10. If git push or pull is required, use: mainsequence project open-signed-terminal <PROJECT_ID>
11. If installed CLI commands or SDK behavior appear older than the docs, upgrade the SDK: mainsequence project update-sdk --path .
12. Verify platform state with the CLI or platform tooling instead of guessing.

Orchestrator Rule

Use the skills as an orchestrated sequence, not as isolated documents.

Default pattern:

1. .agents/skills/project_builder/SKILL.md
2. the relevant domain skill
3. .agents/skills/maintenance/local_journal/SKILL.md after material work if verified state, blockers, scope, next actions, stable references, or historical notes changed

Before the final response:

• consult the maintenance skill whenever project understanding, verified state, or historical record changed during the turn

Always use .agents/skills/project_builder/SKILL.md as the source of truth for project scaffolding, folder structure, and standard repository layout.

Core Working Rules

• keep documentation clear, concise, and accurate
• correct inconsistencies as soon as they are found
• prefer strict code
• avoid defensive guards on hot paths unless justified by a verified requirement
• do not hide failures
• record the exact failing step, command, or workflow
• when hitting a roadblock, blocker, or error, report it back to the user clearly and promptly
• if local code or local docs conflict with the latest Main Sequence docs, record the discrepancy and create follow-up work
• when unsure, verify
• if the active virtual environment is missing libraries that are already declared in requirements.txt, install those missing libraries into the virtual environment before continuing

Main Sequence Verification Rules

When platform state matters, verify it with the CLI and/or platform UI.

At minimum, verify relevant:

• current project selection
• data availability
• jobs
• job runs and logs
• project images
• dashboard or agent resources/releases
• assets
• portfolios
• related platform objects used by the project

Typical verification commands:

• mainsequence project current --debug
• mainsequence project jobs list
• mainsequence project jobs runs list <JOB_ID>
• mainsequence project jobs runs logs <JOB_RUN_ID> --max-wait-seconds 900
• mainsequence project images list
• mainsequence project project_resource list

If live verification is not possible:

• state that clearly
• separate verified facts from assumptions
• provide the exact commands or checks still required

Dependency Management Rules

Manage project Python dependencies with uv.

Rules:

• add new libraries with uv add <package>
• add development-only libraries with uv add --dev <package>
• do not edit dependency declarations or lockfiles manually when uv should manage them
• do not treat requirements.txt as the source of truth for dependency changes
• when dependency changes matter to the project runtime, keep the uv-managed project files and exported requirements in sync

Documentation Rules

• all formal project documentation must live under docs/
• documentation must remain MkDocs-compatible
• keep docs/SUMMARY.md aligned with the docs structure
• the root README.md must remain the entry point and documentation map
• every major project area must have its own page under docs/
• operational and verification procedures must be documented under docs/
• any new feature, workflow, component, or integration must be reflected in documentation

SDK / Platform Issue Handling

If something may be a Main Sequence SDK, documentation, or platform issue:

• record what failed
• explain why it may be a Main Sequence issue
• suggest a concrete improvement
• append the issue to .agents/journal.md
• add actionable follow-up to .agents/tasks.md if still open
• reflect the latest blocker in .agents/status.md

Output Style

• be concise but complete
• prefer explicit facts over vague statements
• surface failures early
• distinguish verified facts from assumptions

Project-State Files Under .agents/

The repository keeps project-state files under .agents/:

• .agents/brief.md
• .agents/tasks.md
• .agents/record.md
• .agents/status.md
• .agents/journal.md

These files are owned by:

• .agents/skills/maintenance/local_journal/SKILL.md for:
  • .agents/brief.md
  • .agents/tasks.md
  • .agents/record.md
  • .agents/status.md
  • .agents/journal.md

Do not improvise their meaning in domain skills. Use the maintenance skill to reconcile them after material work.