Implement GoodDaoHouses MVP smart contract build

[Copilot]

This PR implements the GoodDaoHouses MVP as an actual smart-contract deliverable, replacing the earlier planning-only artifact. It adds the governance contract, the FlowSplitter integration surface it depends on, a mock for focused testing, and targeted governance tests covering the core membership and vote execution flows.

• GoodDaoHouses contract

  • Adds contracts/governance/GoodDaoHouses.sol.
  • Implements the Citizens / Alignment house model with per-house minimum stake configuration.
  • Supports ERC677 transferAndCall registration, direct register-and-stake, additional staking, approval, revocation, and unstake flows.
  • Stores the requested house fields on-chain: citizen name / socialLinks, and alignment name / projectWebpage / missionStatement / distributionStrategy.
  • Uses repo-consistent upgradeable and DAO-aware patterns via DAOUpgradeableContract, NameService, access control, pausing, and avatar-authorized upgrades.

• Membership and voting model

  • Stores member lifecycle state (None, Pending, Active, Revoked, Unstaked) and alignment eligibility records onchain.
  • Activates Citizens members immediately after staking and gates Alignment members behind committee-managed eligibility and approval.
  • Implements quarterly term voting with termDuration and votingTermLength, where the first ballot cast during the voting window lazily creates the vote record and uses timestamp / termDuration as the voteId.
  • Removes dedicated active-member and voter snapshot sets, and derives voter eligibility from active membership plus joinedAt relative to the current term vote start.
  • Stores direct recipient vote units in voteRecipientWeightedVotes, dividing weighted allocations by BASIS_POINTS.
  • Removes the separate finalize step and executes FlowSplitter updates directly from the stored recipient vote units after the voting window closes.

• House of Alignment eligibility registry

  • Adds a GOVERNANCE_COMMITTEE_ROLE-managed on-chain pre-registration registry (HoaEligibilityRecord) for wallets allowed to join the House of Alignment.
  • setHoaEligibility(address, bool) grants or revokes eligibility; preserves full timestamp history (listedAt, updatedAt, delistedAt) on add, remove, and re-add operations.
  • getHoaEligibility(address) exposes the full record for audit and client use.
  • New Alignment member registration reverts with "Not HoA eligible" via the shared _registerMember internal path, so both registerAndStake and transferAndCall entry points behave identically; Citizens registration is unaffected.
  • Emits HoaEligibilityChanged(address indexed account, bool isEligible) on every registry change.

• FlowSplitter execution boundary

  • Adds contracts/governance/IFlowSplitter.sol to mirror the pool-based integration surface needed by the MVP.
  • Executes vote results by translating stored voteRecipientWeightedVotes values into IFlowSplitter.Member[] at the integration boundary.
  • Requires the committee to pre-configure a pool via configureFlowSplitter(splitter, poolId) before vote execution; sends zero-unit updates on member removal or unstake.

• Tests and supporting mock

  • Adds contracts/mocks/MockFlowSplitter.sol for focused governance testing.
  • Adds contracts/mocks/GoodDaoHousesHarness.sol — a test-only subclass that exposes a committee-gated weight setter used to inject values exceeding type(uint128).max for the overflow safety test.
  • Adds test/governance/GoodDaoHouses.test.ts.
  • Covers ERC677 registration, on-chain member field storage, HoA eligibility gating (both registration paths, Citizens bypass, Pending status after eligible registration, timestamp audit trail, committee-only access), alignment approval, lazy term vote creation, join-date-based voter eligibility, direct weighted unit storage, FlowSplitter pool configuration and unit updates, zero-unit cleanup on unstake, voting window boundary conditions, and uint128 cast safety (positive and negative paths).

• Cleanup

  • Removes the mistakenly committed installed skills folder contents and skills-lock.json.

Testing

• ⚠️ yarn compile (blocked in this sandbox because Hardhat could not reach binaries.soliditylang.org to download the Solidity compiler)
• ⚠️ yarn hardhat test test/governance/GoodDaoHouses.test.ts (blocked for the same compiler-download reason)
• ✅ Local solc compile check for contracts/governance/GoodDaoHouses.sol
• ✅ TypeScript transpile check for test/governance/GoodDaoHouses.test.ts

Example of the implemented execution boundary:

_voteRecipientWeightedVotes[voteId][recipient] +=
  (allocation * voterWeight) / BASIS_POINTS;

IFlowSplitter.Member[] memory members = new IFlowSplitter.Member[](recipients.length);
members[i] = IFlowSplitter.Member({
  account: recipient,
  units: uint128(_voteRecipientWeightedVotes[voteId][recipient])
});

Summary by Sourcery

Introduce the GoodDaoHouses governance contract MVP with member-staking houses, a committee-curated HoA eligibility registry, and FlowSplitter-based vote execution.

New Features:

• Add GoodDaoHouses upgradeable governance contract implementing Citizens and Alignment houses with configurable staking requirements and ERC677-based registration and staking flows.
• Add committee-managed House of Alignment eligibility registry (HoaEligibilityRecord) with full timestamp audit trail; gates new Alignment registrations before any state is written.
• Store rich on-chain metadata for members and manage their lifecycle and voting eligibility across term-based voting cycles.
• Integrate with a FlowSplitter pool to translate finalized weighted vote results into member unit allocations, including zero-unit cleanup on removal or unstake.

Enhancements:

• Add IFlowSplitter integration interface and a MockFlowSplitter implementation to provide a testable execution boundary for distributing vote outcomes.

Tests:

• Add GoodDaoHouses governance test suite covering registration paths, HoA eligibility gating, alignment approval, term voting behavior, FlowSplitter execution, uint128 cast safety, and lifecycle edge cases.

[L03TJ3]

@copilot The task was to execute on the plan, not create a new implementation plan. issue #298 is supposed be the implementation plan

[Copilot]

@copilot The task was to execute on the plan, not create a new implementation plan. issue #298 is supposed be the implementation plan

Addressed in 9395d71.

[L03TJ3]

1. remove the installed skills folder
2. I want you to actually execute and implement the requested contract. please re-read [Plan]: GoodDaoHouses MVP implementation outline #298

The deliverible is: the smart-contract build.

@copilot

[Copilot]

1. remove the installed skills folder
2. I want you to actually execute and implement the requested contract. please re-read [Plan]: GoodDaoHouses MVP implementation outline #298

...

Addressed in 478c1c7: removed the committed skills payload and replaced the plan-only change with the GoodDaoHouses contract implementation, FlowSplitter integration surface, and focused governance tests.

[openzeppelin-code]

Implement GoodDaoHouses MVP smart contract build

Generated at commit: a465cbf36534b2f58da0ee30089626460692cf37

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	3 5 0 17 45 70
Dependencies	Critical High Medium Low Note Total	0 0 1 0 139 140

---

For more details view the full report in OpenZeppelin Code Inspector

[sirpy]

1. the fields should be written on chain. for distribution strategy it should be a url to a post on our forum.
2. quarterly/term vote: modulo timestamp by termDuration if result is between 0 and votingTermLength then we are in voting period time frame, first vote will "create" the vote record by calling an internal createAlignmentVote, the voteId can simply be the result of timestamp divided by termDuration..
3. no need for _activeAlignment or _activeCitizens.
4. no need for _voteAlignmentVoters,_voteCitizensVoters, _voteWeightSnapshot assume voting weight for citizen/alignment wont change during vote. check member join date to verify he can participate in current vote.
5. totalUnits + totalWeights not required for "vote" record in createAlignmentVote
6. voteRecipientWeightedVotes should be divided by BASIS_POINTS
   7, finalizeAlignmentVote step is not required.
7. in executeVote each member units is simply the value he got in voteRecipientWeightedVotes

[sirpy]

1. the fields should be written on chain. for distribution strategy it should be a url to a post on our forum.
2. quarterly/term vote: modulo timestamp by termDuration if result is between 0 and votingTermLength then we are in voting period time frame, first vote will "create" the vote record by calling an internal createAlignmentVote, the voteId can simply be the result of timestamp divided by termDuration..
3. no need for _activeAlignment or _activeCitizens.
4. no need for _voteAlignmentVoters,_voteCitizensVoters, _voteWeightSnapshot assume voting weight for citizen/alignment wont change during vote. check member join date to verify he can participate in current vote.
5. totalUnits + totalWeights not required for "vote" record in createAlignmentVote
6. voteRecipientWeightedVotes should be divided by BASIS_POINTS
   7, finalizeAlignmentVote step is not required.
7. in executeVote each member units is simply the value he got in voteRecipientWeightedVotes

@copilot

[Copilot]

1. the fields should be written on chain. for distribution strategy it should be a url to a post on our forum.
2. quarterly/term vote: modulo timestamp by termDuration if result is between 0 and ...

Addressed in 6fb9881.

[sirpy]

@copilot fix unresolved code review conversations. make sure fixes are matched by relevant unit tests

[Copilot]

@copilot fix unresolved code review conversations. make sure fixes are matched by relevant unit tests

Fixed in the latest commit. Here's what was addressed:

1. _registerMember() – invalid house enum — added require(uint8(house) <= uint8(House.Alignment), "Invalid house") at the top of the function so an out-of-range value reverts before any state is written.

2. revokeMember() – non-member revocation — added require(members[account].status != MemberStatus.None, "Not a member") so the function cannot create a phantom Revoked record for an address that never registered.

3. IFlowSplitter.sol – duplicate ISuperToken — removed the empty interface ISuperToken {} stub and replaced it with an import of the existing contracts/token/superfluid/ISuperToken.sol.

4. registerAndStake() – negative-delta underflow — renamed int amount to int256 delta and introduced a separate uint256 transferAmount (0 when delta ≤ 0). Only the non-negative case is transferred and only that amount is forwarded to _registerMember, preventing the uint(negative) underflow.

Each fix is accompanied by a new unit test in test/governance/GoodDaoHouses.test.ts.

[sirpy]

@copilot add the suggested tests
suggestion (testing): Add negative-path tests for voting schedule configuration

Currently only the happy path for setVotingSchedule is tested. Please also cover:

• Calls from non-admin / non-committee signers reverting as expected.
• Invalid parameter combinations (e.g. votingTermLength > termDuration, zero durations, or disallowed past cycle start) reverting with the correct error.
  This will better lock in access control and validation behavior.

Suggested implementation:

    const cycleStartTime = (await houses.cycleStartTime()).toNumber();
    const termDuration = (await houses.termDuration()).toNumber();
    const delta =
      latestBlock.timestamp < cycleStartTime
        ? cycleStartTime - latestBlock.timestamp
        : (() => {
            const offset = (latestBlock.timestamp - cycleStartTime) % termDuration;
            return offset === 0 ? 1 : termDuration - offset + 1;
          })();

    const newCycleStartTime = latestBlock.timestamp + delta;
    const validVotingTermLength = Math.floor(termDuration / 2);

    // happy-path: admin configures schedule
    await expect(
      houses
        .connect(admin)
        .setVotingSchedule(newCycleStartTime, termDuration, validVotingTermLength),
    )
      .to.emit(houses, "VotingScheduleUpdated")
      .withArgs(newCycleStartTime, termDuration, validVotingTermLength);

    // negative-path: non-admin / non-committee cannot configure schedule
    const { stranger } = await loadFixture(fixture);
    await expect(
      houses
        .connect(stranger)
        .setVotingSchedule(newCycleStartTime, termDuration, validVotingTermLength),
    ).to.be.revertedWithCustomError(houses, "OnlyAdminOrCommittee");

    // negative-path: voting term longer than term duration
    await expect(
      houses
        .connect(admin)
        .setVotingSchedule(newCycleStartTime, termDuration, termDuration + 1),
    ).to.be.revertedWithCustomError(houses, "InvalidVotingSchedule");

    // negative-path: zero term duration
    await expect(
      houses
        .connect(admin)
        .setVotingSchedule(newCycleStartTime, 0, validVotingTermLength),
    ).to.be.revertedWithCustomError(houses, "InvalidVotingSchedule");

    // negative-path: zero voting term length
    await expect(
      houses
        .connect(admin)
        .setVotingSchedule(newCycleStartTime, termDuration, 0),
    ).to.be.revertedWithCustomError(houses, "InvalidVotingSchedule");

    // negative-path: cycle start time in the past
    await expect(
      houses
        .connect(admin)
        .setVotingSchedule(latestBlock.timestamp - 1, termDuration, validVotingTermLength),
    ).to.be.revertedWithCustomError(houses, "InvalidVotingSchedule");

To make this compile and match your actual contracts/test helpers you’ll likely need to:

1. Adjust the setVotingSchedule call signature and argument ordering if it differs (e.g. if it accepts (cycleStart, votingTermLength, termDuration) or additional parameters).
2. Replace "VotingScheduleUpdated" with the actual event name (or drop the .to.emit if no event is emitted).
3. Replace the custom error identifiers "OnlyAdminOrCommittee" and "InvalidVotingSchedule" with the actual custom error names (or .to.be.revertedWith messages) used in GoodDaoHouses.
4. Ensure fixture returns a stranger or similar non-privileged signer (e.g. { admin, committee, houses, stranger }). If it currently only returns { admin, committee, houses }, extend it accordingly or derive stranger via ethers.getSigners().
5. If you prefer separate test cases instead of a single expanded one, you can extract the negative-path sections into their own it(...) blocks reusing the same fixture setup.

@copilot fix and add tests
issue (bug_risk): Casting accumulated vote weights from uint256 to uint128 can silently truncate.

Here voteRecipientWeightedVotes[voteId][recipient] is a uint256 but is cast to uint128 without validation. If total weights exceed 2**128 - 1, this will silently truncate and produce incorrect weights for the FlowSplitter.

To avoid this, either:

• Enforce and document an invariant that total weights always fit in uint128; or
• Add an explicit bound check before casting:

uint256 raw = voteRecipientWeightedVotes[voteId][recipient];
require(raw <= type(uint128).max, "Units overflow");
uint128 units = uint128(raw);

so that overflow fails loudly instead of corrupting the result.

[Copilot]

@copilot add the suggested tests
suggestion (testing): Add negative-path tests for voting schedule configuration

...

Done in the latest commit. Here's what was added/changed:

Contract (GoodDaoHouses.sol)

• setVotingSchedule: added require(newVotingTermLength > 0, "Vote term=0") guard alongside the existing checks, so all three invalid-parameter paths now revert with a clear message.
• executeVote: added explicit require(raw <= type(uint128).max, "Units overflow") before the uint128(raw) cast. Note: with the current fixed voter weights (max 400 000 per vote), overflow is practically unreachable — the check is a defensive safety net.

Tests (GoodDaoHouses.test.ts)

• Added stranger signer to the shared fixture.
• setVotingSchedule: non-admin/committee reverts — verifies "Not admin/committee".
• setVotingSchedule: votingTermLength > termDuration reverts — verifies "Vote term > term".
• setVotingSchedule: zero termDuration reverts — verifies "Term=0".
• setVotingSchedule: zero votingTermLength reverts — verifies "Vote term=0".
• executeVote: uint128 cast safety — verifies that a normal two-voter run completes without hitting "Units overflow" and that the stored FlowSplitter units are non-zero.

[sirpy]

@copilot add the negative test case executeVote: uint128 cast safety

[Copilot]

@copilot add the negative test case executeVote: uint128 cast safety

Done in the latest commit. Since normal voting accumulation can never reach type(uint128).max (fixed weights top out at ~400K per voter), the test uses a GoodDaoHousesHarness contract that extends GoodDaoHouses with a committee-gated setVoteWeightForTest setter. The approach required changing voteRecipientWeightedVotes from private to internal (zero external-security impact).

The negative test (executeVote: uint128 cast safety – reverts when accumulated weight exceeds uint128 max):

1. Deploys GoodDaoHousesHarness via UUPS proxy
2. Registers and approves two alignment members, configures the FlowSplitter pool
3. Casts a normal vote (creating the vote record and registering the recipient)
4. Moves past the voting window
5. Injects 2**128 (= type(uint128).max + 1) directly via setVoteWeightForTest
6. Asserts executeVote reverts with "Units overflow"

[L03TJ3]

@copilot

Follow-up: add the missing House of Alignment eligibility registry

Its missing the HoA pre-registration eligibility registry required by the original plan.

Please add a Governance Committee-managed on-chain registry of wallet addresses that are allowed to sign up and stake as House of Alignment members.

Requirements:

• Only GOVERNANCE_COMMITTEE_ROLE can add or remove an eligible wallet.
• HoA registration must revert for a wallet that is not eligible, for both registerAndStake and G$ transferAndCall registration paths.
• Put this check in the shared internal registration path so both entry points behave identically.
• Citizens registration must not use this eligibility gate.
• Eligibility is separate from membership status: an eligible HoA wallet still registers as Pending and requires committee approval to become Active.
• Do not use GoodID as the HoA eligibility source; the registry is committee-curated and GoodID remains relevant to Citizen voting.
• Emit an event for each eligibility change.
• Expose a public read for a wallet’s eligibility. At minimum it must return isEligible; preferably also expose listedAt, updatedAt, and delistedAt timestamps for audit and client use.
• Preserve the registry record/timestamps on removal rather than deleting all history.

Suggested shape:

struct HoaEligibilityRecord {
    bool isEligible;
    uint64 listedAt;
    uint64 updatedAt;
    uint64 delistedAt;
}

function setHoaEligibility(address account, bool isEligible)
    external
    onlyRole(GOVERNANCE_COMMITTEE_ROLE);

function getHoaEligibility(address account)
    external
    view
    returns (HoaEligibilityRecord memory);

Please add tests covering committee-only updates, eligible/ineligible HoA registration through both registration paths, the unchanged Citizens path, and the Pending HoA status after successful registration.

[Copilot]

@copilot

Follow-up: add the missing House of Alignment eligibility registry

...

Done in the latest commit. Here's what was added:

Contract (GoodDaoHouses.sol)

• HoaEligibilityRecord struct (isEligible, listedAt, updatedAt, delistedAt) — all packed into one slot.
• mapping(address => HoaEligibilityRecord) private hoaEligibility added before __gap; gap reduced from [50] to [49] to preserve storage layout.
• setHoaEligibility(address, bool) gated by GOVERNANCE_COMMITTEE_ROLE; sets listedAt only on first listing, updates delistedAt on removal, always updates updatedAt, and emits HoaEligibilityChanged.
• getHoaEligibility(address) view returning the full record.
• Eligibility gate in _registerMember: new House.Alignment registrations revert with "Not HoA eligible" unless the wallet is in the registry. The check is applied only for new members (isNewMember == true) so existing alignment members can re-stake without re-checking eligibility, and the Citizens path is entirely unaffected.

Tests (GoodDaoHouses.test.ts)

• registerAlignment helper updated to accept committee as its first argument and internally call setHoaEligibility(signer, true) before the token transfer, keeping all existing tests working.
• 6 new tests added:
  • setHoaEligibility: only GOVERNANCE_COMMITTEE_ROLE can update eligibility
  • setHoaEligibility: records listedAt on first listing, delistedAt on removal, and preserves history
  • HoA registration via transferAndCall reverts when wallet is not eligible
  • HoA registration via registerAndStake reverts when wallet is not eligible
  • HoA registration succeeds and status is Pending after eligibility is granted
  • HoA registration via transferAndCall succeeds and status is Pending after eligibility is granted
  • Citizens registration is unaffected by the HoA eligibility gate

[sirpy]

no need for stake only for registerandstake

[sirpy]

no need for only stake. we only use regiseration

[sirpy]

@copilot add relevant tests

[sirpy]

@copilot add tests suggested in comment

[sirpy]

The hoa eligibility registry is not required.
anyone can stake, but they need to be eventually approved by the committee in approveAlignmentMember