StakeToken is implemented in src/StakeToken.sol. Build succeeds and all nine scratch tests pass.

What the contract does

• Constants for name "Stake Token", symbol "STK", 18 decimals. Total supply is immutable at 1,000,000 STK, minted once to holder in the constructor with a Transfer event from the zero address.
• Implements transfer, approve, and transferFrom with the standard Transfer and Approval events. Balance and allowance getters are public mappings.
• An allowance of the maximum uint256 is treated as infinite and is not decreased on transferFrom.
• No mint, burn, owner, or any privileged role. The only untracked change in git is the src directory, and only that one file exists in it. The scratch test in test/scratch is disposable.

Choices I made beyond the spec

• The constructor rejects a zero-address holder, and transfers or approvals to the zero address revert. These are standard ERC-20 guards and do not affect the integrated pool or distributor.
• Revert reasons are string messages prefixed with "StakeToken:". If the pool or distributor tests expect specific reverts from the token, they should match on these strings.
• The functions return true on success rather than reverting silently, so a caller using a plain IERC20 interface with bool returns will work.

Assumptions relevant to the other contracts

• The pool and distributor will pull tokens via transferFrom after an explicit approve. The distributor's drip presumably calls transfer to the pool or approves the pool and calls notifyRewardAmount. Either path works with this token.
• The repo has no foundry.toml, so forge uses defaults for src and test locations. My scratch test avoids forge-std since lib is off limits and empty.

Nothing was committed, since the task did not ask for a commit.

Done. The RewardsDistributor contract is implemented in src/RewardsDistributor.sol, builds cleanly, and passes 10 scratch tests. Nothing was installed and no config files were touched. The file is untracked and uncommitted, since no commit was requested.

What the contract does

• Immutables: token, pool, weeklyAmount. Constructor rejects zero addresses and a zero weekly amount.
• No owner, no withdraw: The NatDoc states that tokens sent to the contract can only leave through drip() to the pool, and that other tokens sent there are unrecoverable.
• drip(): Permissionless. Reverts with DripNotReady when the timestamp is before nextDrip, and with NothingToDrip when the balance is zero. Transfers min(weeklyAmount, balance) to the pool, calls notifyRewardAmount with that amount, and sets nextDrip to now plus 7 days. Missed weeks are not caught up.
• nextDrip starts at 0, so the first drip is allowed at deployment.
• Event Dripped(amount, nextDrip) is emitted after state is updated and before the external calls, so a reentrant pool cannot reorder logs.

Scratch tests cover: immutables, constructor guards, zero-balance revert with unchanged state, full and partial drips, the exact boundary at nextDrip, missed weeks not accumulating, resume after drain, and the integrator's predicted-CREATE-address pattern. The mock pool asserts it already holds the tokens when notified.

Assumptions about the other contracts

• The token's transfer returns a boolean. The distributor reverts on false. If StakeToken returns nothing, the call will revert on ABI decoding, which is still safe.
• The pool's notifyRewardAmount(uint256) expects the tokens to already be in the pool when called. The distributor transfers first, then notifies.
• The pool is expected to ignore or accept a zero-argument caller check. The distributor does not need any privileged role on the pool, but if the pool restricts notifyRewardAmount to the distributor address, the integrator must deploy the pool with the distributor's predicted address, as the task describes.

Two lint warnings remain and are intentional: comparing against block.timestamp is the specified behavior, and the other warning is in the scratch test only.

Implemented StakingPool.sol with reward accounting, idle reward re-emission, principal protection, events, and CEI/reentrancy protection.

Offline forge build succeeded; all 22 tests passed, including fuzz tests and mock distributor integration.

Assumes tokens have no transfer fees or rebasing. Empty-stake exit() reverts. No deployment performed.

The three contracts work together without changes: forge test passes 14 of 14, including a fuzzed run of the four invariants with no failures. Nothing was deployed.

Wiring: the test deploys the token, then the pool using the distributor's predicted address from vm.computeCreateAddress, then the distributor. It checks that the distributor landed exactly at the predicted address and that the pool and distributor each point at the other. STK is both the stake and the reward token, and there are no mocks: every test uses the real contracts.

What the tests cover:

• Three stakers over three weeks: rewards split as expected each week (2,500/7,500, then 1,250/3,750/5,000, then 2,000/0/8,000), and everyone gets their principal back.
• Drip timing: a second drip inside 7 days reverts, including one second before the next drip is due, and succeeds exactly when it is due. After 10 weeks the 100,000 STK runs out and the next drip reverts.
• Rewards with nobody staked: they are re-emitted the following week, both for a fully empty week and for a partly empty one.
• Attacks:
  • Staking 1 second before a drip and withdrawing 60 seconds after earns only that time share.
  • Stake, drip and withdraw in the same block earns nothing.
  • notifyRewardAmount from a stranger reverts, even after the stranger sends tokens to the pool.
  • A reward notification backed only by staked principal reverts.
  • Daily claims over 21 days never dip into principal.
• Invariants, checked across 64 runs of 64 random actions each (stake, withdraw, claim, exit, time jumps, drips, stranger notifications), with none of those actions reverting:
  • pool balance ≥ total staked + sum of earned
  • total claimed ≤ claimed + earned ≤ total dripped
  • a stranger's notification never succeeds
  • no STK is created or lost

Interface guesses by the writers (all compatible; the full table is in docs/INTEGRATION.md):

• nextDrip, totalStaked and balanceOf are public variables, so their automatic getters match the agreed view functions. nextDrip starts at 0, so the first drip can happen immediately.
• The distributor transfers tokens before notifying the pool, which is what the pool expects.
• Both use a 7-day period. A late drip doesn't catch up missed weeks; emission just pauses.
• The distributor sends the smaller of 10,000 and its remaining balance.
• Both files declare their own IERC20, each a subset of what StakeToken provides. The names don't clash because the tests import only the contracts they need.
• The distributor requires transfer to return true; the pool accepts tokens that return nothing. StakeToken returns true, so both work.

Finding (can't happen in this system): when the pool accepts a reward notification, it checks the new amount against "balance minus total staked". That figure still includes rewards people have earned but not yet claimed. If the distributor address ever notified without sending tokens, the pool would promise more rewards than it holds. test_OverCommittedNotifyStillCannotTouchPrincipal shows principal stays safe even then: the late claimer's claim reverts, but everyone can still withdraw in full. The real distributor always sends tokens first, so I left the pool unchanged. Making the check exact would mean the pool tracking rewards that are owed but unpaid.

Limitations:

• Each weekly notification strands under 604,800 wei of rounding dust in the pool, which is never re-emitted. The tests allow a 1e9-wei tolerance for this.
• The test file declares five cheatcodes. getNonce is one more than the task listed; it's used to predict the distributor's address.
• These are local Foundry runs only (forge 1.8.3, default config): no deployment, no forked network, and a modest fuzz run. Passing tests are not a security review.

I committed test/StakingIntegration.t.sol and docs/INTEGRATION.md. Git had no author identity configured, so I committed under the "IdentityMD Worker" name