Approved workflow

Release Kudos (ERC-20 symbol KUDO) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Kudos (KUDO), total supply 1,000,000,000 KUDO with 18 decimals, minted once to the deployer. Application contract: KudosEpochs. Currency: KUDO is the app's working currency. KudosEpochs takes the KUDO address as its only constructor argument (constructorArgs ["$token"]), stores it immutable, exposes it as token(), and holds no KUDO at deploy; users get KUDO by swapping Sepolia ETH in the launch pool the factory seeds. Every payment in is approve + SafeERC20.safeTransferFrom (permit not required). KudosEpochs has no payable function and no receive/fallback, so it never holds ETH. Payouts are pull-based (the recipient calls to collect; nothing is pushed to third parties), follow checks-effects-interactions and are nonReentrant. No owner, admin, pause or upgrade path. Weekly kudos with optional KUDO tips. Epoch = (block.timestamp - deployTimestamp) / 7 days. Every address may give 5 kudos per epoch. give(to, count, tipPerKudo): to != caller and != address(0), 1 <= count <= the caller's remaining kudos this epoch; if tipPerKudo > 0 the contract pulls count * tipPerKudo KUDO from the giver and credits it to the recipient's withdrawable balance. Kudos received are counted per epoch and lifetime; they are counters, not tokens, and cannot be transferred. Unused kudos do not roll over. withdraw() pays credited KUDO. Kudos counts are free and therefore sybil-able; tips only ever move the giver's own KUDO, so sybils cannot extract value (the README says so). Views: currentEpoch(), remaining(account), receivedIn(epoch, account), lifetimeReceived(account), tipsReceived(account), withdrawable(account), token(). Events: Kudos(epoch, from, to, count, tip), Withdrawn. Tests (Foundry) must cover: the 5-per-epoch limit across several gives, the epoch rollover at the exact boundary, self-kudos and zero address refused, tips with count > 1, withdraw twice, and the invariant that KUDO held equals the sum of withdrawable balances. The independent adversarial review must attack: giving more than 5 kudos in an epoch (including in the rollover block), tip arithmetic overflow or mis-crediting, and reentrancy on withdraw. Deploy through the project factory, then publish a one-page website to give kudos with an optional tip, show your remaining kudos and this epoch's leaderboard (built from Kudos events), and withdraw tips. The page reads the KUDO address from KudosEpochs.token(), shows the connected wallet's KUDO balance, allowance and withdrawable balance, has an Approve step before every paying action and a Withdraw button, and says that KUDO comes from swapping Sepolia ETH in the launch pool (no in-page swap). Lists come from contract views and events only (no backend, no indexer). Keep it to one small page; the static export has index.html in dist/.

Sepolia (11155111) only. GitHub publication and IPFS hosting are approved. Launch token: a separate fixed-supply ERC-20, 18 decimals, no constructor arguments, exactly 1,000,000,000 minted to msg.sender, no mint or admin functions. The factory sends that supply to LP and rewards, so no application contract may need a launch-token balance at deploy. Application contracts are fully configured in nonpayable constructors using only address, uint, bool or bytes32 arguments (no strings, arrays, proxies, delegatecall or selfdestruct); anything else is set at runtime. No owner unless the request names one, and then it is $owner. No external oracles, VRF or keepers: randomness is commit-reveal or a future blockhash read within 256 blocks with a refund path. foundry.toml sets bytecode_hash = "none". The website is a static export with index.html in dist/. Site label lab-kudos-epochs.

Build KUDO and KudosEpochs (KudosEpochs takes constructorArgs ["$token"]; kudos carry optional KUDO tips) with Foundry tests and an independent adversarial review, deploy them through the project factory, then build the one-page website against the live deployment.

One static page, no framework beyond what the skill needs, reading the live deployment's ABI and address. Approve KUDO before paying; show KUDO balance and allowance and the withdrawable balance.