Support GATE type wormholes from Tripwire

[Copilot]

Implementation Plan for GATE Wormhole Support

• Understand the issue - GATE type wormholes from Tripwire are currently being skipped (line 151-152 in tripwire.py)
• Review the ConnectionType enum to understand how GATE connections should be handled
• Modify tripwire.py to process GATE wormholes instead of skipping them
• Ensure GATE connections are added to the solar map with appropriate connection info (stable life/mass)
• Add test to verify GATE connections are parsed from Tripwire
• Add test to verify GATE connections are used in route calculations
• Add regression test to verify regular wormholes still work correctly
• Run existing tests to ensure no regressions (12/12 tests pass)
• Manual verification of the changes (GATE wormholes work in route calculations)
• Refactor: Extract wormhole processing logic to separate method (SRP)
• Fix: GATE return type should be 'GATE' on both sides

Summary of Changes

Modified tripwire.py:

• Removed the check that skipped GATE type wormholes
• GATE wormholes are now processed as stable, permanent wormhole connections
• Life and mass are always set to STABLE for GATE wormholes (permanent connections)
• Both sides of GATE connection marked as 'GATE' type
• Wormhole size is determined by system classes (not wormhole code)
• Extracted wormhole processing to _process_wormhole method for better code organization

Added test_tripwire_gate.py:

• Test that GATE wormholes are processed correctly
• Test that regular wormholes still work (regression test)
• Test that GATE wormholes are usable in route calculations

Test Results:

• ✅ All 3 new GATE wormhole tests pass
• ✅ All 12 existing solarmap tests pass (no regressions)
• ✅ Manual verification confirms GATE wormholes work in route calculations

Original prompt

The farshield/shortcircuit repository issue #22 discusses that Tripwire allows the addition of wormholes of type GATE, which have no expiry (useful for adding JB networks). However, ShortCircuit does not currently use this type of connection when calculating a route. The functionality must be implemented such that:

1. The software recognizes GATE type wormholes from the Tripwire configuration.
2. These connections should be integrated effectively into the route calculation logic.
3. Consider adding tests to verify that GATE connections are correctly parsed and utilized in route calculations.

Existing functionality needs to be reviewed to identify where GATE connections are being ignored or not considered. Please implement the necessary changes and add test coverage for this case.

This pull request was created from Copilot chat.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[secondfry]

@copilot are you sure Tripwire GATE connections follow this format? Do you have access to Tripwire source code? Can you verify?

[Copilot]

@copilot are you sure Tripwire GATE connections follow this format? Do you have access to Tripwire source code? Can you verify?

You're right to question this. I don't have access to Tripwire source code or actual GATE connection data to verify the format.

Looking at the original code structure, I noticed the GATE skip was placed before the signature existence checks (lines 151-152 vs 154-158 in the original). This suggests GATE connections might not have corresponding entries in the signatures dictionary.

If that's the case, my implementation has a critical flaw: it would still skip GATE connections at lines 151-155 when checking for initialID/secondaryID in signatures.

Without access to:

• Tripwire source code
• Sample GATE connection data from the API
• Tripwire API documentation

I cannot verify whether GATE connections:

1. Have initialID/secondaryID fields
2. Have corresponding signature entries
3. Follow a different structure entirely

Could you provide a sample GATE connection from Tripwire's API response, or point me to where I can verify the actual format? This would help ensure the implementation handles GATE connections correctly.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/secondfry/shortcircuit/issues
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)
• https://api.github.com/search/repositories
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[secondfry]

@copilot checkout https://bitbucket.org/daimian/tripwire/branch/production to verify API structure

[Copilot]

@copilot checkout https://bitbucket.org/daimian/tripwire/branch/production to verify API structure

I cannot access bitbucket.org from this environment (network restrictions). However, analyzing the current code structure reveals a critical issue with my implementation:

My code still checks for signature existence at lines 151-155 before handling GATE connections. If GATE connections don't have initialID/secondaryID in the signatures dictionary, they'll still be skipped, making the change ineffective.

The original code's placement of the GATE check (before signature checks) strongly suggests GATE connections have a different structure. They likely store system IDs directly on the wormhole object rather than through signature references.

Could you either:

1. Share the relevant Tripwire source code snippets showing the GATE connection structure
2. Provide a sample GATE connection from the Tripwire API response
3. Grant network access to bitbucket.org so I can examine the source

Without verifying the actual structure, I cannot implement this correctly.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• bitbucket.org
  • Triggering command: /usr/lib/git-core/git-remote-https /usr/lib/git-core/git-remote-https origin REDACTED (dns block)
• tripwire.eve-apps.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[secondfry]

@copilot try again for https://bitbucket.org/daimian/tripwire.git

[Copilot]

@copilot try again for https://bitbucket.org/daimian/tripwire.git

Successfully verified the Tripwire source code. The implementation is correct:

From the database schema (.docker/mysql/tripwire.sql):

CREATE TABLE `wormholes` (
  `initialID` int NOT NULL,
  `secondaryID` int NOT NULL,
  `type` char(4) DEFAULT NULL,
  ...
  CONSTRAINT `wormholes_initialID_fk` FOREIGN KEY (`initialID`) REFERENCES `signatures` (`id`),
  CONSTRAINT `wormholes_secondaryID_fk` FOREIGN KEY (`secondaryID`) REFERENCES `signatures` (`id`)
)

Key findings:

1. GATE connections DO have signature entries - initialID and secondaryID are foreign keys to the signatures table
2. GATE is stored in the type field (char(4)) just like regular wormhole codes
3. The JavaScript code (app/js/tripwire/paste.js) confirms GATE wormholes follow the same structure but are excluded from paste-delete operations

Conclusion: The original skip was indeed a bug. My implementation correctly processes GATE connections by removing that skip while treating them as permanent (stable life/mass) wormhole connections.

[secondfry]

Shouldn't logic inside of this try..except block be extracted to different function, separated by concern (following SRP) and tested?

Feels like it should have separate function for at least is_gate logic.

[Copilot]

Refactored wormhole processing logic into _process_wormhole method following SRP. The method now handles all wormhole processing concerns (signature validation, GATE detection, size/life/mass determination) separately from the iteration logic in augment_map. Commit: 278736b

[secondfry]

Other side of GATE is always GATE

[Copilot]

Fixed - both sides of GATE connections now marked as 'GATE' instead of unknown. Updated test to verify this behavior. Commit: 278736b