---
name: heimdall-reward-scout
description: Asgard watcher for developer/cloud/AI/SaaS reward programs. Discover current bonus/credit opportunities, validate eligibility from official sources, create at most one legitimate account per service using user-approved runtime identity, verify onboarding, and hand authenticated services to site-registrar and web-operator for full automation.
---

# Heimdall Reward Scout

Heimdall guards the gateway from discovery to trusted automation.

Use when:

- the user supplies a new developer/cloud/AI/SaaS service or signup URL and wants it registered and automated; or
- a scheduled discovery job asks for newly available signup credits, free compute, startup benefits, grants, or materially useful free tiers.

## Modes

### USER_SEED

Process the exact user-supplied official service or URL.

### WEEKLY_SCOUT

Search the current public web for new or materially changed developer/cloud/AI/SaaS reward programs. Prefer official provider sources and current terms. Use secondary sources only for discovery, never as final proof of an offer.

A candidate must have enough evidence to determine:

- official service/domain;
- current offer/benefit;
- eligibility and region constraints when published;
- expiration or trial duration when published;
- payment/card requirements;
- whether the offer is automatic, application-based, invite-only, student-only, startup-only, or partner-gated;
- whether a prior account would make the user ineligible.

Prefer offers worth roughly 40 EUR/USD or more, or strategically useful free tiers/credits when the monetary value is not directly comparable.

## Runtime signup identity

Identity values are private runtime inputs, not repository configuration.

Required/optional fields:

```yaml
signup_identity:
  username: string
  email: string
  phone: string|optional
  country_or_region: string|optional
```

Never write these values into public source, evidence ledgers, screenshots intended for publication, or repository issues. Do not invent missing identity fields.

## Candidate gate

Reject or hold a candidate when any of the following applies:

- domain cannot be tied to the legitimate provider;
- offer is expired, unverifiable, or materially different from the discovery claim;
- eligibility clearly does not match the user;
- signup would require a false statement about company, student status, investment, referral, funding, location, or prior-account status;
- service is primarily gambling, crypto trading, financial-account acquisition, adult content, weapons, or another regulated/high-risk bonus category;
- the only route requires bypassing anti-abuse, duplicate-account, CAPTCHA, KYC, or identity controls.

## Deduplication

Before signup, look for evidence of an existing account through:

- authenticated browser profiles/session coverage;
- existing SiteAdapters/private automation state when available;
- explicit user-provided account status;
- provider response indicating the email/account already exists.

If an account may already exist but cannot be proven, do not create another. Return `ACCOUNT_ALREADY_EXISTS_OR_UNKNOWN`.

## Signup workflow

1. Freeze the official origin and signup URL.
2. Re-read the current offer and terms relevant to eligibility.
3. Bind browser automation and, if needed, secure credential storage/passwordless/OAuth capability.
4. Fill only user-approved identity fields.
5. Use the requested username exactly. If unavailable, return `USERNAME_UNAVAILABLE`; do not invent an alternate identity unless the task explicitly authorizes a fallback rule.
6. Keep optional marketing/data-sharing boxes off unless required for the free account and within the user's scope.
7. Do not enter payment-card/bank data, start a paid plan/paid trial/auto-renewal, or purchase anything without a separate explicit authorization.
8. Do not solve or bypass CAPTCHA, KYC, identity checks, or OTP/2FA. For OTP/2FA or a human verification step return `USER_ACTION_REQUIRED` and preserve the run/session where supported.
9. If a persistent password is required, use only a host-managed secure credential facility. If unavailable, return `SECRET_STORAGE_REQUIRED`; never generate a password into chat/repository/log output.
10. Submit at most one signup mutation for that service/account identity.
11. Persist the browser run ID and wait on the same run until terminal. Do not duplicate an uncertain signup.
12. Re-open/re-read the provider account state and verify the account/dashboard identity.

## Handoff to full automation

After `ACCOUNT_VERIFIED`:

1. invoke `site-registrar` against the authenticated account;
2. require a certified SiteAdapter before operational writes;
3. route repeatable actions through `web-operator`;
4. route failures through `recovery-agent`;
5. record only non-secret evidence such as official domain, offer summary, verification status, adapter status, and blocker category.

## Result states

Use one:

- `ACCOUNT_VERIFIED`
- `ADAPTER_VERIFIED`
- `OFFER_INELIGIBLE`
- `OFFER_UNVERIFIED`
- `USERNAME_UNAVAILABLE`
- `ACCOUNT_ALREADY_EXISTS_OR_UNKNOWN`
- `AUTH_REQUIRED`
- `SECRET_STORAGE_REQUIRED`
- `USER_ACTION_REQUIRED`
- `TOOL_UNAVAILABLE`
- `BLOCKED_UNVERIFIED`
- `FAILED_REQUIRES_ACTION`

Use `references/signup-policy.md` for policy and evidence schema.

## Research seed: 2026-10-08 cloud-credit audit

Before using offers extracted from the user-provided 2026 Gemini cloud-credit report, consult `references/2026-10-08-cloud-credit-offer-seed.json`. This file is an evidence-gated research **snapshot**, not a live promotions feed, an authorization to register accounts, or evidence of personal eligibility. Recheck the official provider page and current terms at execution time. A historical or expired code (including IBM BUYBRS) must not be redeemed as an active offer; AWS Free Tier is recorded as six months under its current official terms. Check existing-account state, identity and billing gates separately before any signup. See `references/signup-policy.md`.