How to divorce smartcontract from a full-node?

On my laptop the 2 gig blocks are too large for my 1.0.7 BSV node to process in any reasonable time,
so I have to give up maintaining my BSV full node
and instead I need to change to a small pruned node which will call to outside service APIs to get block headers and transactions.

To divorce smartcontract from the fullnode,
is it true that I only have to make changes in

for example where it calls
r.client.GetRawTransactionVerbose(ch) from node.go line 173
or
r.client.GetRawTransactionVerboseAsync(ch) from line 237

or must I also make changes somewhere else?

The index of the fullnode is only needed by the various GetTransaction calls, right?
So I just have to change the various GetTransactions calls to get from the new " BSV Java Components Library (JCL)" service announced by NChain last week here LiteClient Toolbox; Open-source project releases - Bitcoin SV, right?
I can use a pruned local node for any sendTransaction calls, right?
NOTE that even a pruned node will CHOKE on loading 2 gig blocks,
but the send will work nonetheless or I can use BSV Java Components Library (JCL) for sends as well.
spynode will have to be changed to call BSV Java Components Library (JCL) to listen for transactions which involve the wallet address.
I just need to be able to send txs and do the smartcontract sync to calculate wallet balances - without needing any sophisticated validation or double-spend detection.
My application is for POC and evaluation purposes, and to roughly design the smart contracts.
Then I want to send contract metadata to tokenized to get into actual production.
I have some NFT customers lined up.
I believe I can also use testnet for development because there does not appear to be any large blocks going into testnet so far. But testnet does not really shakeout the kinks like mainnet does.

The full node is needed to send txs to the network, scan for incoming transactions to the smart contract, and to fetch transactions containing outputs being spent into incoming transactions. When there are standardized services to provide this data we will look into connecting the open source smart contract agent to them.

Until then, that sounds right. Get tx requests should fail from a pruned node, but the rest should work.

Just to reiterate, smart contract agent is designed to be run on servers that are reliable, always on, and powerful. When better services are available then we can shift much of it to services.