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.

• 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.
  • Creates the pool on first execution, reuses the same pool on later executions, and sends zero-unit updates on member removal or unstake.

• Tests and supporting mock

  • Adds contracts/mocks/MockFlowSplitter.sol for focused governance testing.
  • Adds test/governance/GoodDaoHouses.test.ts.
  • Covers ERC677 registration, on-chain member field storage, alignment eligibility and approval, lazy term vote creation, ballot replacement, join-date-based voter eligibility, direct weighted unit storage, first pool creation, subsequent member-unit updates, and zero-unit cleanup on unstake.

• 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])
});

[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: 6fb988123691eb3ffeb633f10832dae57e655971

🚨 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.