segregated witness – Making a uncooked Segwit transaction from scratch and getting Signature have to be zero for failed CHECK(MULTI)SIG operation

I’m making an attempt to create a Segwit transaction on TESTNET from scratch whereas referencing an internet information:
https://medium.com/coinmonks/creating-and-signing-a-segwit-transaction-from-scratch-ec98577b526a

My BIP-39 mnemonics code:

differ toast alert sweet orbit raccoon wagon hour thunder kiwi house cigar

My TESTNET BIP-32 grasp public key derived Segwit Bech32 deal with with derivation path ‘m’:

tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj

The deal with profile will be seen from right here.

Only for simplicity of debugging, the derivation ‘m’ will likely be used solely.

For extra context the Grasp Public Key compressed format:

03D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A

For extra context the Grasp Public Key uncompressed format:

04D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385AE1DEED79187355D35FDABAF74DFD186A8B8C9FE1D6357AA46750A47B86ED16CF

The uncooked BIP-32 Seed:

1CD4561EF82D35F9EE2E95ED63B68BB91ADA8967E1D98FA4080637A4CC310BE99DD285F82F45EE004ADC408F8B93C2A829A5B811104496A6FB0301E062CBC813

The uncooked Grasp Personal Key used for the digital signing later:

13D84CAC526896CEF2594D71621D2AEDC90F9DAEA88A1751AD99E35868E0021B

I want to ship myself (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj) some funds (0x5503000000000000 / 853 satoshis) utilizing my very own deal with (tb1qzjgctgz9t98dmkwp4z26whg6tl4w9s6rl6hwwj).

So, I start to create the Segwit inputs that may then be double-SHA256 hashed then signed.

It follows the BIP143 outlined steps:

Double SHA256 of the serialization of:
 1.  nVersion of the transaction (4-byte little endian)
 2.  hashPrevouts (32-byte hash)
 3.  hashSequence (32-byte hash)
 4.  outpoint (32-byte hash + 4-byte little endian) 
 5.  scriptCode of the enter (serialized as scripts inside CTxOuts)
 6.  worth of the output spent by this enter (8-byte little endian)
 7.  nSequence of the enter (4-byte little endian)
 8.  hashOutputs (32-byte hash)
 9.  nLocktime of the transaction (4-byte little endian)
 10. sighash kind of the signature (4-byte little endian)

// 1.  nVersion of the transaction (4-byte little endian)
<<< 01000000

// 2.  hashPrevouts (32-byte hash)
>>> printf "4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< 04dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f

//  3.  hashSequence (32-byte hash)

>>> printf "ffffffff" | xxd -p -r | sha256sum | xxd -p -r | sha256sum

<<< 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044

//  4.  outpoint (32-byte hash + 4-byte little endian) 

<<< 4E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0 00000000

//  5.  scriptCode of the enter (serialized as scripts inside CTxOuts)

<<< 1976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ac

//  6.  worth of the output spent by this enter (8-byte little endian)

<<< e803000000000000

//  7.  nSequence of the enter (4-byte little endian)

<<< ffffffff

// 8.  hashOutputs (32-byte hash)
          
>>> printf "e803000000000000 16 0014149185A045594EDDD9C1A895A75D1A5FEAE2C343" | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< 7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f

// 9.  nLocktime of the transaction (4-byte little endian)
<<< 00000000

// 10. sighash kind of the signature (4-byte little endian)
<<< 01000000

// Hashing with double Sha256

>>> printf 0100000004dc164c0a705f5d2d57fd42e6896a94394e6966ed0b116a64adfaa9310b848f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650444E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A0000000001976a914149185A045594EDDD9C1A895A75D1A5FEAE2C34388ace803000000000000ffffffff7c007a193409e64199438db0ba4349809fbcc42c17e7167cbc06deec4cc0998f0000000001000000 | xxd -p -r | sha256sum -b | xxd -p -r | sha256sum -b

<<< c2636fae9487354f47e4e92458a7e856f717533c6d01e1c5fda5b06c4a1976a8

The encoded digital signature consequence:

30450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76

Lastly, formatted right into a uncooked transaction under:

010000000001014E2F5CCED0DC6D7B229AB43381A7DDBAB759C457C3366D8435782120493133A00000000000FFFFFFFF015503000000000000160014149185A045594EDDD9C1A895A75D1A5FEAE2C343024830450221008B61503427B2292F781405712DF878B207D8B89FC86D60B1A68D479CA6C6FF2302203BB1F7F5F7E2B9050BA481310C997F6F078F5ED25564AEC85277EB56BA98FD76012103D7DE86033E1C815BA0E3589938B7AC906B728F1F2C771542E203E32B80A3385A00000000

The printed outcomes throws the next error:

sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Signature have to be zero for failed CHECK(MULTI)SIG operation)"}

I’ve checked the digital signatures many instances and ran validation on the signatures and public key with assumption that each one the above addresses and scripts are legitimate.

How do I repair the failed broadcast ? What are the causes of the failed broadcast ?